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ABSTRACT 


This  thesis  explores  the  Bahrain  Defense  Force  (BDF)  needs  for  a  decision 
support  system  in  the  area  of  analyzing,  establishing  and  maintaining  the  organizational 
structures  of  BDF  units.  It  also  identifies  the  BDF  measures  that  must  be  taken  to  qualify 
a  certain  unit  structure. 

Subsequently,  the  thesis  designs  and  develops  a  specific  DSS  prototype  that  can 
aid  BDF  decision  makers  and  planners  perspectives  in  this  area.  Creating  this  prototype 
has  involved  three  different  layers  to  be  investigated:  the  data,  the  models  and  the  user 
interfaces.  The  data  layer  consists  of  a  Microsoft  Access™  database  application  that 
houses  BDF  Units,  Manpower,  Vehicles,  Weapons,  Salaries,  and  Jobs  information.  The 
model  layer  consists  of  two  Microsoft  Excel™  spreadsheets  that  contain  Infantry 
Battalion  and  enhanced  Armor  Battalion  HR  optimization  models.  The  UI  layer  consists 
of  user  controls,  input/output  forms,  queries,  reports,  and  visualization  aids  (i.e.  charts 
and  pivot  tables).  These  interfaces  were  developed  using  MS  Access  capabilities. 
Consequently,  the  BDF  DSS  is  an  integration  of  database  and  optimization  technology 
using  widely  available  desktop  tools. 

The  general  benefits  of  this  DSS  are  reduced  costs  for  data  gathering, 
computation,  and  data  presentation,  and  added  value  resulting  from  investigating  more 
alternatives,  doing  more  sophisticated  analyses  of  alternatives,  using  better  methods  of 
comparing  alternatives,  and  making  quicker  and  better  decisions. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Given  the  complexity  of  military  organizational  structures  and  the  need  to 
establish  modernized  military  forces,  BDF  decision  makers  or  planners  require  database 
technology  to  support  the  processes  of  analyzing,  establishing  and  maintaining  different 
kinds  of  BDF  organizational  structures.  For  instance,  during  the  study  phase,  and  before 
approving  a  proposed  BDF  unit  organizational  structure,  BDF-HQ  needs  to  know  the 
estimated  fixed  cost  and  the  running  cost  in  establishing  and  maintaining  such  a  unit. 
Also,  BDF-HQ  needs  to  compare  all  cost  drivers  of  a  proposed  unit  to  other  existing  units 
which  would  generate  more  choices  for  BDF-HQ  decision-makers. 

Currently,  the  BDF  current  system  of  doing  such  processes  is  done  manually  and 
indeed  there  are  many  associated  anomalies  to  that  system  which  sometimes  impair  the 
growth  of  BDF  in  different  aspects.  Consequently,  and  as  an  illustration  of  the  required 
decision  support  tool,  this  research  involves  building  and  prototyping  a  database  and 
associated  decision  model  to  support  the  following  BDF  requirements: 

1.  To  build  an  organizational  structure  and  establishment  satisfying  manpower  and 
operational  equipment  requirements  (vehicles  and  weapons)  of  an  organization. 

2.  To  track  and  highlight  the  vacancies  and  requirements  of  the  new  and  existing 
organization. 

3.  To  compute  the  estimated  operational  cost  of  establishing  and  maintaining  a  unit. 

4.  To  compare  the  cost  of  maintaining  two  or  more  units  in  an  organization. 

5.  To  illustrate  a  current  BDF  unit  situation  with  respect  to  actual  cost  vs.  budgeted 
cost. 

6.  To  illustrate  the  BDF  overall  situation  with  respect  to  actual  cost  vs.  budgeted 
cost. 

7.  To  support  decision  makers  and  planners  in  BDF-HQ  for  effective  and  efficient 
resource  planning  with  respect  to  manpower  and  operational  equipment. 


1 


B.  OBJECTIVE  AND  RESEARCH  QUESTIONS 

The  objective  of  this  research  is  to  define,  design  and  implement  a  prototype 
version  of  a  decision  support  system  (DSS)  that  addresses  the  Bahrain  Defense  Force 
(BDF)  requirements  for  analyzing,  establishing  and  maintaining  the  organizational 
structures  of  BDF  units.  The  DSS  will  combine  database  technology  and  optimization 
models. 

The  primary  research  question  with  respect  to  this  objective  is  to  determine  the 
appropriate  design  heuristics  in  tenns  of  data,  models,  and  user  interfaces  for  a  system  to 
support  decisions  about  the  creation  and  maintenance  of  organizational  structures  in  the 
BDF.  There  are  also  several  subsidiary  research  questions: 

1.  What  are  relevant  performance  metrics  for  maintaining  BDF  organizational 
structures  of  manpower  and  equipment? 

2.  What  database  architecture  is  required  to  support  such  a  DSS  tool? 

3.  What  analytical  models  are  appropriate  for  developing  robust  cost  models?  How 
can  software  systems  supporting  such  models  be  integrated  with  the  database 
architecture? 

4.  What  visualization  tools  and  user  interfaces  are  appropriate  for  supporting 
decision  makers  using  this  DSS? 

C.  SCOPE 

The  scope  of  the  thesis  will  include: 

1 .  Identification  of  the  current  processes  of  analyzing,  approving  and  maintaining  a 
BDF  unit  organizational  structure. 

2.  Identification  and  prototyping  a  suggested  database  model  and  DSS  interface  that 
would  satisfy  a  critical  mass  of  BDF  requirements  and  objectives. 

3.  Identification  of  alternative  solutions  to  such  a  DSS  tool. 

4.  Only  a  prototype  will  be  developed,  which  can  be  used  to  generate  requirements 
for  a  full  operational  system.  It  is  beyond  the  scope  of  this  thesis  to  develop  an 
operational  system. 
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D.  METHODOLOGY 

The  methodology  used  to  fulfill  the  requirements  for  this  thesis  will  consist  of  the 
following  steps: 

1.  Conduct  a  literature  review  of  books,  professional  journals,  magazines  articles, 
web-based  materials,  and  other  library  infonnation  sources.  The  reviews  will 
address  topics  on  decision  support  systems,  database  technologies,  operations 
research,  human  resources,  costing  models,  cost-benefit  analysis,  and  military 
organizational  structures. 

2.  Gather  sample  data  from  Planning  and  Organization  Directorate  on  several 
existing  and  proposed  organizational  structures  of  BDF  units  to  examine  the 
functions  needed  in  the  proposed  system. 

3.  Identify  user  interface  requirements  by  interviewing  key  users  in  POD  (the 
intended  DSS  users).  The  GUI  requirements  will  be  in  terms  of  input  controls  as 
well  as  output  displays  such  as  reports,  queries,  “what  if’  capabilities,  and  other 
visual  displays. 

4.  Design  underlying  database  schema  that  has  a  complete  logical  view  of  the 
database  using  a  software  application  called  Visible  Analysis.  Once  the  database 
schema  is  created  and  analyzed  (normalized),  it  can  then  be  converted  to  the 
desired  database  application  such  as  Microsoft  Access. 

5.  Identify  and  build  associated  cost  models  using  simulation,  what-if  analysis, 
and/or  optimization  (linear  programming)  models. 

6.  Build  a  standalone  database  prototype  in  Microsoft  Access  in  which  can  be  easily 
migrated  to  a  client-server  database  in  the  future. 

7.  Design  and  implement  user  interfaces. 

8.  Test  prototype  system. 

E.  PRIMARY  BENEFIT  OF  THE  STUDY 

This  thesis  will  develop  a  prototype  DSS  tool  for  manpower  and  operational 

equipment  resource  planning  in  support  of  BDFHQ  decision  makers  and  planners. 
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Specifically,  this  thesis  will  propose  a  DSS  application  which  can  provide  the  BDF  better 
vision  in  planning  for  its  current  and  future  organizational  structures.  The  prototype  can 
serve  as  a  preliminary  requirements  specification  for  a  fully  operational  system  in  the 
BDF. 

F.  THESIS  ROADMAP 

The  coming  chapters  will  address  the  following  subjects: 

1 .  Chapter  II  will  provide  an  overview  of  the  current  BDF  system  of  maintaining  its 
organizational  structures  of  manpower  and  equipment  that  identifies  processes  of 
analyzing,  approving  and  maintaining  those  organizational  structures.  This 
chapter  will  also  address  relevant  performance  metrics  used  to  evaluate  BDF 
organizational  structures  of  manpower  and  equipment,  and  finally  will  discuss  the 
current  system  and  factors  that  have  led  to  its  suboptimal  performance. 

2.  Chapter  III  will  discuss  a  database  design  that  satisfies  the  critical  mass  of  BDF 
requirements  and  objectives  described  in  the  first  chapter. 

3.  Chapter  IV  will  develop  and  illustrate  examples  of  optimization  models  that  can 
be  linked  to  the  database  model  to  provide  the  requisite  decision  support. 

4.  Chapter  V  will  discuss  the  prototype  that  has  been  developed  with  emphasis  upon 
the  user  interfaces  such  as  input/output  forms,  queries,  reports,  and  model  “what 
if’  analyses. 

5.  Finally,  Chapter  VI  will  conclude  the  research  and  include  recommendations  for 
future  research.  Furthermore,  the  core  benefits  of  applying  such  a  tool  will  also  be 
discussed. 
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II.  OVERVIEW  OF  THE  CURRENT  BDF  SYSTEM  OF 
MAINTAINING  ORGANIZATIONAL  STRUCTURES  FOR 
MANPOWER  AND  EQUIPMENT 


A.  INTRODUCTION 

The  BDF  builds  organizational  structures  to  include  all  manpower  and  operational 
equipment  resources  that  will  be  allocated  to  a  unit.  The  resources  of  operational 
equipment  in  a  unit  are  weapons,  vehicles,  and  communication  instruments.  However,  the 
request  to  study  major  changes  in  the  organizational  structure  of  an  existing  unit  or 
establishing  new  ones  gets  initiated  by  the  BDF  top-level  positions  (i.e.  Commander  in 
Chief  (CINC),  Minister  of  Defense  (MOD),  Chief  of  Staff  (COS)... etc)  for  many 
reasons: 

1.  BDF  needs  to  develop  the  organizational  structure  of  its  forces  according  to  a 
potential  external  threat  that  has  arisen  to  the  homeland. 

2.  BDF  needs  to  reorganize  its  forces  to  be  compatible  with  its  friendly  forces 
structures. 

3.  When  BDF  plans  to  receive  recent  operational  equipment  (i.e.  tanks,  ships, 
weapons,  radars... etc). 

4.  Or  when  the  original  mission  assigned  to  a  unit  has  changed  and/or  expanded  in 
such  a  way  that  the  current  organizational  structure  of  that  unit  does  not  match 
with  the  new  mission. 

In  addition,  all  proposed  structures  must  be  presented  to  the  HQ  officials  before 
approval.  Thus,  it  is  important  that  the  process  of  creating  organizational  structures  have 
computer-based  tools  that  provide  accuracy,  efficiency  and  predictability  in  presenting 
information  which  in  turn  eventually  lead  to  effective  decisions.  However,  at  this  time  the 
current  BDF  system  for  maintaining  organizational  structures  of  manpower  and 
equipments  is  done  manually,  and  the  number  of  staff  assigned  in  this  area  is  not 
sufficient  to  handle  multiple,  complex  tasks  simultaneously. 

Therefore,  the  purpose  of  this  chapter  is  to  describe  the  present  process  of 
maintaining  the  BDF  organizational  structures  and  the  expected  performance  associated 
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with  it.  The  description  of  the  processes  will  help  to  justify  the  BDF  baselines  for 
acquiring  a  decision  support  system  as  well  as  provide  specifications  for  that  system. 


B.  CURRENT  PROCESSES 

The  current  processes  of  maintaining  the  BDF  organizational  structures  are 
illustrated  in  Figure  1  below.  They  are  somewhat  dependent  upon  each  other  and  involve 
four  main  steps  as  follows: 


Figure  1 .  Current  Process  for  Maintaining  BDF  Organizational  Structures 
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1.  Receiving  Requests  to  Study  Future  Establishment  of  a  New  Unit  or  to 
Reorganize  the  Structure  of  an  Existing  Unit 

A  request  to  alter  an  existing  structure  of  a  unit  or  to  make  slight  adjustments  to 
that  structure  is  usually  initiated  by  the  unit  commander.  Those  requests  are  received  on  a 
daily  basis,  whereas  orders  to  study  future  units  come  from  the  HQ  top  level  officers  on  a 
monthly  basis  or  sometimes  weekly  basis. 

2.  Prioritizing  and  Scheduling  those  Studies 

Upon  Planning  and  Organization  Directorate  (POD)  director  instructions,  only 
studies  that  require  a  comprehensive  analysis  are  prioritized  and  timetabled.  Requests  that 
need  only  small  modifications  to  the  structure  are  directly  put  into  the  execution  cycle  of 
the  structure  alteration  process,  once  they  get  the  first  approval  to  do  so.  Moreover,  the 
first  approval  test  is  part  of  this  process  and  is  applied  to  quickly  detennine  whether  the 
minor  changes  in  a  structure  are  economically  and  operationally  feasible  or  not.  Since  the 
focus  of  this  research  is  to  define  major  current  processes  for  maintaining  the 
organizational  structures  of  BDF,  the  descriptions  of  minor  structure  alteration  processes 
will  be  neglected  because  they  are  easy  to  maintain  and  do  not  require  huge  efforts. 


3.  Building  and  Analyzing  an  Inclusive  Structure  Study 

To  conduct  such  a  study  the  POD  planners  must  be  freed  to  do  one  study  at  a  time 
since  this  process  needs  a  huge  amount  of  time  and  effort  to  be  achieved.  Therefore,  this 
step  requires  decomposing  an  overall  process  into  sub-processes  because  it  accounts  for 
about  80%  of  the  POD  planner  workload.  These  sub-processes  are  as  follow: 

a.  Preparing  the  Proposed  Hierarchical  Structure  and  Tables  of  the 
Intended  Unit 

The  size  of  the  unit  determines  the  time  and  effort  needed  to  accomplish 
this  stage.  Normally,  the  POD  staff  uses  the  MS-Office  applications  to  build  the  proposed 
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unit  tables  along  with  other  applications  (i.e.  FileMaker-Claries)  to  fabricate  the  final 
product  of  hierarchical  structures. 

b.  Estimating  the  Running  and  Fixed  Costs  of  the  Structure  and 
Comparing  it  to  Similar  Existing  Units 

The  next  step  is  to  insert  the  computed  number  of  resources  that  has  been 
allocated  to  the  structure  in  spreadsheets  to  generate  estimations  of  the  most  important 
cost  drivers  in  the  structure.  The  costs  resulting  from  manpower  resources  have  the  top 
priority  in  this  sub-process  because  it  accounts  for  60%  to  70%  of  the  total  budget  needed 
to  run  this  structure.  The  manpower  cost  is  detennined  based  upon  basic  rank  salary, 
allowances  associated  with  rank  (i.e.  transportation,  social... etc),  and  allowances 
associated  with  job  (i.e.  position,  job  type... etc).  Additionally,  POD  planners  must  gather 
data  regarding  the  initial  cost  of  operational  resources  such  as  weapons,  vehicles  and 
wire/wireless  communication  devices  every  time  they  do  this  process.  Once  all 
estimations  are  calculated,  the  matching  sub-process  is  started;  this  is  currently  done 
manually.  When  comparing  similar  existing  units  to  the  proposed  unit,  overstaffed 
structures  might  appear  to  the  POD  staff  that  require  chopping  if  no  justification  has 
accompanied  it.  Thus,  when  putting  the  intended  structure  under  a  mini-scope  that  is  still 
done  by  hand  might  not  illuminate  tiny  and  might  be  major  anomalies  to  that  structure. 
Then,  a  careful  feasibility  check  is  done  before  proceeding  to  the  next  step.  If  this  test  is 
not  passed,  then  the  structure  must  be  modified  and  fed  back  to  the  preparing  sub-process 
again.  Moreover,  unique  proposals  need  experts  to  decide  on  the  maximum  ceiling  of  the 
organizational  structure  for  this  kind  of  unit.  Customarily,  a  committee  headed  by  the 
POD  director  is  responsible  to  conduct  such  studies  that  recommend  more  than  one 
option  for  the  unit  structure. 


c.  Setting  up  the  Structure  Information  for  the  Briefing,  and  then 
Presenting  it  to  HQ 

After  editing  the  proposed  hierarchical  structure  and  finalizing  it,  the  POD 
staff  translates  those  structures  into  multi-format  tables  that  hold  numbers  of  manpower 
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and  operational  equipments  and  the  costs  related  to  them  in  order  to  brief  the  BDF-HQ 
officials.  To  generate  those  tables  that  hold  estimations  of  fixed  and  running  cost  of  the 
intended  structure,  a  substantial  computing  job  must  be  done  to  give  a  clear  picture  to  the 
decision-makers  group.  Obviously,  this  stage  is  critical  and  the  presentation  contents  need 
to  be  well-organized  with  all  cost  drivers  tailored  to  reasonable  figures  within  the  BDF 
budget  in  order  to  persuade  the  necessary  decision  makers.  Usually  before  presenting  the 
final  product  of  a  proposed  unit,  a  POD  director  directs  his  planners  to  work  within 
boundaries  and  constraints  of  how  a  proposed  structure  might  look  and  what  parts  of  the 
structure  need  to  be  focused  upon.  Finally,  either  an  approval  feedback  is  returned  to  the 
POD  director,  or  further  studying  is  needed.  In  the  first  case,  the  POD  planners  are  still 
responsible  to  complete  the  work  they  have  started  and  submit  the  final  official  draft  of 
the  proposed  unit  to  be  signed  by  the  BDF  CINC.  In  the  second  case,  the  POD  planners 
need  to  rework  the  whole  study  and  repeat  the  preparation  and  analysis  process  to  include 
modifications  that  have  been  approved  during  the  presentation  and/or  additional 
suggestions  for  the  proposed  unit. 

d.  Archiving  All  Studies  and  Distributing  Copies  Among  BDF 
Directorates 

This  process  is  essential  to  keep  performing  all  future  structure  studies  that 
require  information  about  previous  endorsed  structures  and  rejected  ones  as  well  for 
comparison  purpose.  Currently,  a  hardcopy  of  any  approved  structure  and  its  related 
tables  are  kept  in  the  POD  cabinet  whereas  softcopy  is  saved  in  a  dedicated  hard  disk 
with  floppy  disks  as  a  backup.  However,  a  unit  organizational  structure  could  have 
several  files  of  different  types.  For  instance,  MS  Word  files  contain  unit  mission,  unit 
roles,  and  unit  job  description  for  the  jobs  it  currently  has,  MS  PowerPoint  or  FileMaker 
files  contain  all  hierarchical  structures  of  that  unit,  and  finally,  MS  Excel  files  contain  all 
information  about  unit  tables  such  as  different  formats  of  manpower  list,  weapon  list,  etc. 
All  BDF-HQ  directorates  and  the  commander  of  that  unit  must  receive  a  hard  copy 
through  the  regular  BDF  mail  system. 
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C.  PERFORMANCE  METRICS 

During  the  study  stage  of  establishing  new  unit  structure,  there  are  two  primary 
performance  metrics  of  effectiveness  that  decision  makers  use  to  decide  which 
organizational  structures  are  better  (or  worse)  than  others.  These  measures  are  taken  into 
account  by  POD  planners  to  verify  how  feasible  and  reliable  is  the  unit  structure  before 
supporting  the  idea  of  endorsing  this  structure.  The  measures  are  as  follows: 

1.  Unit  Structure  Outlay  Costs 

Theses  can  be  either  fixed  costs  or  running  costs  resulting  from  creating  a  unit 
structure  that  requires  resource  allocations  in  order  to  operate  according  to  the  unit’s 
assigned  missions.  The  fixed  costs  involve  expenditures  that  are  paid  once  during  the  unit 
lifecycle,  and  which  are  also  considered  as  the  unit’s  assets.  For  instance,  building  unit 
facilities,  purchasing  unit  weapons  and  vehicles  are  examples  of  the  fixed  costs 
associated  with  establishing  a  BDF  unit.  The  running  costs  concern  expenditures  that  are 
paid  periodically  (weekly,  monthly  or  annually)  during  the  whole  unit  lifecycle  to  make 
the  unit  fully  operational.  Examples  of  unit  running  costs  are  manpower  costs  (such  as 
salaries,  allowances,  promotions  and  family  health  care  expenses),  training  costs, 
ammunition  costs,  and  maintenance  costs  of  the  equipments..  Therefore,  the  POD 
planners  try  to  achieve  a  cost-effective  unit  structure  which  will  stay  within  the  BDF 
budget  constraints,  and  will  not  exceed  it  under  the  assumption  that  no  new  operational 
equipment  is  intended  to  be  purchased  in  the  near  future. 

2.  Unit  Structure  Quality 

This  measure  means  operationally  how  feasible  or  practical  is  the  unit  structure 
before  implementation.  Does  it  serve  the  assumed  unit  roles  and  tasks?  Different  tests 
conducted  by  POD  planners  to  verify  this  measure  are  as  follows: 
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a.  Combat  Doctrine  Test 

The  unit  structure  must  initially  comply  with  the  BDF  combat  doctrine. 
For  example,  an  infantry  battalion  must  be  comprised  exactly  of  three  infantry 
companies,  one  supporting  company,  and  one  administrative  company.  Each  infantry 
company  encompasses  three  infantry  platoons. 

b.  Category  Test 

The  unit  manpower  is  divided  into  three  major  categories:  operations, 
administrative,  and  technical  manpower.  The  unit  type  can  only  determine  the  minimum 
and  the  maximum  manpower  percentages  that  will  be  assigned  to  each  category  (i.e.  field 
artillery  battalion  can  have  70-80%  for  operation  vacancies,  15-25%  for  administrative 
vacancies,  and  5-10%  for  technical  vacancies).  Thus,  POD  planners  try  to  define  those 
interval  constraints  for  each  model  and  adhere  to  them  as  much  as  possible  to  obtain  a 
robust  unit  structure. 


c.  Military  Standard  Test 

The  unit  structure  must  obey  the  military  standards  in  filling  the  jobs 
required  to  operate  and  maintain  a  certain  weapon  or  vehicle.  Also,  POD  planners  use 
friendly  forces  structures,  if  available,  as  a  reference  when  creating  such  unit  structures. 

d.  Rank  Distribution  Test 

Finally,  the  unit  structure  ranks  must  be  shaped  as  a  pyramid  for  both 
officers  and  enlisted  ranks  as  shown  in  Figure  2  below.  In  the  enlisted  case  for  instance, 
the  number  of  corporal  ranks  (third  lowest  rank)  must  always  be  greater  than  (best 
scenario)  or  at  least  equal  to  (worst  scenario)  the  number  of  sergeant  ranks  (fourth  lowest 
rank).  Again,  the  unit  type  can  only  determine  a  rank’s  intervals. 
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Figure  2.  Ordering  the  BDF  Ranks  Distribution 


As  a  result,  the  typical  unit  structures  are  those  which  best  satisfy  both 
performance  measures  mentioned  above,  and  POD  planners  use  those  measures  when 
comparing  two  or  more  of  BDF  unit  structures  to  determine  which  is  better. 

D.  CURRENT  SYSTEM  PERFORMANCE 

BDF-FIQ  is  always  willing  to  update  or  establish  new  organizational  structures  of 
its  forces,  reengineer  its  business  processes,  and  adopt  technologies  whenever  that  is 
deemed  best  for  BDF.  In  general,  the  overall  performance  of  the  current  BDF  system  of 
maintaining  its  organizational  structures  is  not  efficient  and  effective  enough  to  support 
concurrently  the  BDF  development  process  and  its  ambitious  perspectives.  There  are 
many  reasons  or  factors  that  have  led  to  such  weak  outcome  of  this  system: 

1.  Shortfall  of  POD  Planners 

As  mentioned  before,  the  number  of  POD  planners  and  staff  is  not  sufficient  to 
handle  the  nonstop,  increasing  workload.  This  degrades  the  overall  performance  of  that 
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system.  Subsequently,  the  current  POD  staff  can  conduct  only  one  comprehensive  study 
at  a  time,  and  the  related  outcome  is  often  not  sufficient  to  achieve  any  but  the  minimum 
requirement.  The  recommended  solution  to  solve  this  problem  will  be  discussed  in 
chapter  4. 

2.  No  Embedded  Computer-Based  System  in  the  Current  Processes 

BDF-HQ  has  owned  personal  computers,  servers  and  mainframe  computers  since 
the  late  1980’s  and  started  networking  them  shortly  thereafter.  However,  the  POD  system 
of  maintaining  the  BDF  organizational  structures  does  not  fully  utilize  computer 
capabilities  to  achieve  maximum,  or  even  moderate  benefits.  For  example,  a  computer- 
based  system  can  be  built  to  hold  customized  business  rules  that  control  and  validate 
actions  taken  by  the  system  users.  Consequently,  the  lack  of  using  an  automated  tool  such 
as  a  decision  support  system  has  prevented  the  current  POD  system  from  considering 
more  potentially  useful  decision  alternatives.  The  benefits  of  a  DSS  include  the 
following: 

1 .  Discourage  premature  decision-making  and  alternative  selection. 

2.  Generate  multiple  and  higher  quality  alternatives  for  consideration. 

3.  Improve  response  time  of  decision  maker. 

4.  Explore  and  test  multiple  problem-solving  strategies. 

5.  Increase  the  decision  maker’s  ability  to  tackle  large  scale  and  complex  problems. 

6.  Explore  multiple  analysis  scenarios  for  a  given  decision  context. 

7.  Improve  the  reliability  of  a  decision  process  outcome. 


3.  Several  Data  Files  are  Used  to  Maintain  One  Unit  Structure 

This  is  a  big  dilemma  in  the  current  system  which  needs  additional  file  processing 
efforts  to  retrieve  data,  create  reports  and  so  forth.  By  splitting  and  isolating  the  data  in 
many  files,  the  following  drawbacks  may  occur  in  the  system  perfonnance: 
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a.  Data  Integrity  Degradation 

For  instance,  if  a  change  is  made  in  one  file  of  a  unit  structure,  then  POD 
planners  must  manually  feed  all  subsequent  updates  in  the  remaining  files  that  contain  the 
same  information  about  that  unit.  Actually,  entering  data  more  than  once  will  increase  the 
data  error  probability,  and  much  of  the  data  is  duplicated. 

b.  Integration  and  Speed  Problems 

Since  there  is  no  real  or  virtual  link  between  data  files  that  contain 
information  about  all  BDF  structures,  POD  planners  have  to  do  extra  work  to  integrate 
those  files  to  extract  common  reports  needed  to  enhance  the  decision-making  process  in 
maintaining  the  BDF  organizational  structure. 


c.  The  Difficulty  of  Presenting  Data  in  the  POD  User ’s  Perspective 
It  is  difficult  to  present  separate  file  data  in  a  fonn  that  seems  natural  to 
POD  planners  and  decision  makers.  This  complexity  arises  because  with  manual  file 
processing,  data  relationships  must  be  maintained  which  is  not  an  easy  task  to  do.  Also, 
making  queries  based  on  certain  or  set  of  criteria  is  time-consuming  in  the  current 
situation. 

4.  Lack  of  Using  Analysis  Techniques  in  the  Current  System 

Presently,  POD  does  not  implement  any  kind  of  analysis  strategies  (i.e. 
simulation,  forecasting,  linear  programming  and  what-if  analysis  tools)  in  order  to  obtain 
optimum  numbers  of  resources  allocated  to  a  unit.  In  fact,  if  these  capabilities  were  used 
in  the  current  system,  POD  could  effectively  reduce  cost  and  achieve  better  quality  output 
in  establishing  and  maintaining  a  unit  organizational  structure.  Thus,  without  having  such 
techniques  in  the  POD  system,  a  quantum  performance  will  never  be  reached. 

In  a  nutshell,  the  aforementioned  factors  highlight  some  of  the  system 
shortcomings  in  maintaining  BDF  organizational  structures.  The  current  situation  is 
almost  completely  manual,  and  does  not  automate  any  part  of  the  system  processes  in  a 
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way  that  could  lower  BDF  cost  and  enhance  the  speed  and  the  quality  of  building  and 
updating  BDF  structures. 

The  first  step  in  designing  a  DSS  to  support  the  requirements  outlined  above  is  to 
identify  the  data  requirements  and  an  associated  database  structure  for  housing  the  data. 
In  the  next  chapter,  we  will  analyze  and  design  a  database  model  that  meets  the  BDF  data 
requirements  and  objectives.  The  database  design  will  flow  from  the  perfonnance  metrics 
described  above. 
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III.  THE  DATABASE  MODEL 


A.  INTRODUCTION 

The  objective  of  this  research  is  to  propose  a  decision  support  system  (DSS) 
solution  that  addresses  the  Bahrain  Defense  Force  (BDF)  needs  for  analyzing, 
establishing  and  maintaining  the  organizational  structures  of  BDF  units  in  order  to 
facilitate  more  effective  decision-making  processes  in  that  area  .  The  DSS  solution  will 
be  built  on  top  of  an  automated  database  application  that  contains  all  information 
required  for  establishing  the  costs  of  building  and  maintaining  an  operational  military 
unit.  This  in  turn  will  allow  BDF  decision-makers  and  planners  to  track  and  monitor  the 
manpower,  staffing,  and  operational  support  requirements,  and  to  propose  or  approve  a 
cost-effective,  quality  organization  structure. 

The  components  of  a  DSS  can  generally  be  classified  into  three  distinct  parts: 
data,  models,  and  user  interface.  [Ref.  1]  The  data  component  of  a  DSS  is  where  the 
various  activities  associated  with  retrieval,  storage,  and  organization  of  the  relevant  data 
for  the  particular  decision  context  are  managed.  Additionally,  the  data  management 
system  provides  for  the  various  security  functions,  data  integrity  procedures,  and  general 
administration  duties  associated  with  using  the  DSS.  The  model  component  is  similar  to 
the  data  component  in  performing  the  retrieval,  storage,  and  organizational  activities 
associated  with  the  various  quantitative  models  that  provide  the  analytical  capabilities  for 
the  DSS.  Finally,  the  user  interface  is  a  key  element  in  DSS  functionality.  It  provides  the 
vehicle  through  which  the  user  navigates  through  the  DSS,  views  output  displays  and 
performs  what-if  analyses. 

This  chapter  will  focus  mainly  on  the  DSS  data  design  phase,  which  emphasizes 
development  of  a  conceptual  data  model  that  fulfills  the  requirements.  However,  in  order 
to  clarify  the  system  design,  this  chapter  will  start  with  a  brief  discussion  about  the 
system  or  prototype  analysis  to  outline  the  investigation  of  the  problem  and  requirements 
(functional  and  interface  requirements). 
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B.  ANALYSIS  PHASE 

The  BDF  DSS  system  must  embrace  a  database  application  along  with  an 
embedded  DSS  interface.  Therefore,  the  database  tool  must  be  designed  to  meet  the  BDF 
functional  requirements  and  support  the  DSS  user  interface  requirements  as  follows: 

1.  Establish  an  organizational  structure  that  satisfies  manpower  and  operational 
equipment  requirements  (vehicles  and  weapons)  of  an  organization.  The  database 
structure  must  segregate  the  unit  entity  from  the  resources  entities  and  create 
relationships  among  each  in  order  to  facilitate  the  appropriate  database 
management. 

2.  Track  and  highlight  the  staffing  requirements  of  the  new  and/or  existing 
organizations.  The  database  shall  allow  the  computation  of  manpower  shortfalls 
or  surpluses  in  a  selected  unit  or  an  organization  as  a  whole.  This  database 
application  feature  will  enable  the  decision-makers  to  execute  informed  and 
responsive  changes  to  manpower  recruitment  and  retention  policies  when  needed. 

3.  Compute  the  estimated  operational  cost  of  establishing  and  maintaining  a  unit 
based  on  resources  allocated  to  that  unit.  The  database  shall  automatically 
calculate  all  cost  drivers  for  an  existing  unit  structure  or  a  proposed  one. 
Additionally,  the  calculated  cost  drivers  for  a  unit  structure  must  accompany  any 
changes  made  to  the  unit  resources.  In  other  words,  the  DSS  user  can  see  the 
instant  cost  impact  whenever  he/she  makes  modifications  in  the  unit  resources. 

4.  Compare  the  cost  of  maintaining  two  or  more  units  in  an  organization.  The  model 
must  allow  the  DSS  user  to  visualize  and  present  cost  infonnation  in  different 
ways,  e.g.  numerical  or  graphical  presentations. 

5.  Illustrate  a  current  BDF  unit  situation  with  respect  to  actual  cost  vs.  budgeted 
cost.  The  database  must  allow  the  DSS  user  to  see  the  difference  between  the  unit 
actual  cost  and  the  unit  planned  cost. 

6.  Illustrate  the  overall  BDF  situation  with  respect  to  actual  cost  vs.  budgeted  cost. 
The  database  must  differentiate  the  approved  unit  structures  from  the  proposed 
ones  in  order  to  estimate  the  BDF  overall  cost  situation  (current  or  actual  cost  vs. 
planned  cost). 
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7.  Support  decision  makers  and  planners  in  BDF-HQ  for  effective  and  efficient 
resource  planning  with  respect  to  manpower  and  operational  equipment.  This 
requirement  symbolizes  the  ultimate  BDF  goal  in  designing  the  database  model 
which  should  provide  its  users  with  the  following  capabilities: 

a.  Analytical  models  that  can  be  built-in  or  linked  to  the  database 
application.  These  models  are: 

1)  Optimization  models  that  help  to  find  the  best  solutions  for  cost 
and  manpower  based  on  user-defined  constraints.  The  next 
chapter  will  discuss  this  point  in  more  detail. 

2)  Simulation  of  an  existing  or  proposed  unit  structure  in  the 
database  by  providing  a  tool  to  duplicate  the  unit  information  and 
related  resources  but  with  a  different  unit  identity.  This  process 
will  widen  the  unit  structure  alternatives  and  help  to  obtain  the 
desired  cost  and  quality  in  the  unit  structure  under  study. 

3)  What-if  models  that  help  to  meet  the  desired  specification  of  the 
suggested  unit  structure  in  a  short  time.  The  what-if  technique 
can  be  described  as  sensitivity  analysis  that  allows  generation  of 
different  unit  structure  scenarios  that  trigger  automatic 
computations  whenever  a  change  is  made  to  the  unit  resources. 

b.  Visualization  tools  and  graphical  representations  such  as  pivot  tables  and 
charts  can  be  utilized  when  comparing  two  or  more  of  unit  structures. 

c.  Defining  and  creating  queries  and  reports  in  fonnats  that  are  in  accordance 
with  the  users’  needs.  This  will  support  the  demonstration  process  of  the 
proposed  unit  structure. 

C.  DATABASE  DESIGN  PHASE 

The  process  for  building  the  BDF  DSS  data  component  is  Analysis  (Logical 
Design),  Physical  Design,  and  Process  Design. 
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1.  Logical  Design  of  BDFDSS 

The  conceptual  data  model  can  be  created  accordingly  from  the  previously 
defined  database  requirements.  As  shown  in  Figure  3  below,  the  main  entities  for  this 
model  are  Unit,  Manpower,  Weapons,  Vehicles,  Jobs  and  Salaries.  Their  associated 
primary  keys,  attributes,  and  relationships  are  defined  in  the  Entity-Relationship  (ER) 
diagrams  shown  in  Appendix  A.  The  standard  forms  (normalization),  entity  integrity  and 
referential  integrity  rules  were  considered  when  building  this  data  model  to  achieve  data 
consistency  and  at  the  same  time  to  avoid  update,  insertion,  and  deletion  anomalies. 


Visible  Systems  Corporation  EDUCATIONAL/TRAINING  Version 


Figure  3.  Entity  Relationship  Diagram  of  the  Database  Model  (BDF  DSS) 


There  is  a  vast  amount  of  information  and  literature  available  in  the  area  of 
relational  database  design.  Therefore,  the  following  definitions  are  provided  for  clarity: 

Relation  is  a  table,  or  flat  file,  with  columns  and  rows 
Relation  attribute  is  a  column  in  a  relation. 

Primary  key  is  one  or  more  attributes,  the  value(s)  of  which  uniquely  identify 
each  row  in  a  relation. 
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Composite  Key  is  a  primary  key  consisting  of  more  than  one  attribute. 

Foreign  key  is  a  set  of  attributes  in  one  relation  that  constitute  a  key  in  some 
other  (or  possibly  the  same)  relation;  used  to  indicate  logical  links  between 
relations. 

Entity  integrity  rule  states  that  no  key  attribute  of  any  row  in  a  relation  may 
have  a  null  value. 

Normal  forms  are  rules  for  structuring  relations  that  eliminate  anomalies. 

Referential  integrity  rule  states  that  the  value  of  a  non-null  foreign  key  must  be 
a  primary  key  value  in  some  relation. 

Update  anomaly  refers  to  the  data  inconsistency  resulting  from  data  redundancy 
and  partial  updates. 

Deletion  anomaly  refers  to  the  unintended  loss  of  data  due  to  deletion  of  other 
data. 

Insertion  anomaly  refers  to  the  inability  to  add  data  to  the  database  due  to  the 
absence  of  other  data. 

Integrity  constraints  are  rules  that  restrict  the  values  that  may  be  present  in  the 
database.  Codd’s  relational  data  model  includes  several  constraints  that  are  used 
to  verify  the  validity  of  data  in  a  database  as  well  as  to  add  meaningful  structure 
to  the  data.  [Ref.  2] 


The  entities  and  relationships  in  this  model  are  developed  via  the  Visible 
Analyst™  application  that  allows  a  subsequent  examination  of  each  relation  to  assure  it 
follows  desirable  normalization  criteria.  Visible  Analyst  can  also  generate  easily  the 
database  schema  shown  in  Appendix  B  that  defines  the  database  structure,  its  tables, 
relationships,  domains,  and  business  rules.  [Ref.  3]  The  main  entities  are  described  as 
follows: 


a.  Unit  Entity 

The  most  important  entity  (central  entity)  in  this  model  is  the  unit  since 
the  total  cost  of  establishing  a  unit  or  organization  is  derived  from  the  other  secondary 
entities  such  as  manpower,  vehicles,  etc.  In  other  words,  the  unit  entity  acts  as  the  unit 
repository  that  holds  information  about  all  BDF  unit  resources  which  a  BDF  unit  needs. 
The  primary  key  of  this  entity  is  the  unit  identification  number  (Unit  ID). 
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b.  Manpower  Entity 

This  entity  represents  the  model  human  resource  planning  part  which  in 
fact  is  the  most  costly  resource  that  a  BDF  must  consider  when  establishing  new  units. 
Hence,  it  is  the  second  most  important  entity,  which  holds  all  job  information  and  their 
related  costs  for  a  BDF  unit.  This  entity  has  three  relationships  with  Unit,  Jobs  and 
Salaries  entities.  First,  many  Unit  manpower  instances  (rows)  in  the  Manpower  entity 
will  be  linked  to  one  instance  from  Unit  entity.  On  the  other  hand,  many  Jobs  and  Ranks 
instances  can  be  shared  by  many  Units  assuming  the  unit  ID,  rank  and  the  job  type  are 
not  repeated  in  Unit  manpower.  This  means  that  the  key  of  manpower  entity  is  the 
combination  of  unit  ID,  rank  and  the  job  type.  Accordingly,  the  unit  manpower  data  can 
be  constructed  based  on  both  Salary  and  Job  entities  that  have  information  about  current 
BDF  jobs  and  their  estimated  costs,  which  includes  basic  salaries  and  allowances. 
Therefore,  linking  those  entities  to  the  manpower  entity  is  essential  in  order  to  share  one 
source  of  current  BDF  jobs  and  one  source  of  salary-based  ranks  data.  In  addition,  the 
Manpower  entity  must  hold  two  essential  properties  (attributes)  that  specify  the  available 
and  occupied  number  of  jobs  in  a  unit.  The  first  will  correspond  to  the  budgeted  number 
of  jobs;  whereas  the  second  will  represent  the  actual  number  of  jobs  (current  manpower 
situation  of  a  unit),  and  finally  the  difference  between  them  will  correspond  to  the 
shortfall  or  surplus. 


c.  Vehicles  and  Weapons  Entities 

Both  entities  have  similar  attributes  and  primary  keys.  They  symbolize  the 
resource  catalogs  of  BDF  operational  equipment  which  a  BDF  unit  needs.  In  addition,  the 
costs  established  for  those  entities  include  not  only  the  fixed  costs  for  a  type  of  vehicle  or 
weapon  but  also  the  running  cost  to  maintain  it.  All  existing  and  proposed  BDF  units  will 
share  those  entities  as  needed  but  in  different  quantities  via  the  indirect  many-to-many 
relationships  depicted  in  Appendix  A.  As  a  result,  two  associative  entities  are  required 
between  Vehicle/Weapon  and  Unit  entities  to  create  a  many-to-many  relationship.  Those 
entities  are  called  UnitJVehicles  and  Unit_Weapons.  The  primary  key  of  Unit_Weapons 
for  example,  is  the  weapon  type  plus  unit  ID. 
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In  summary,  the  resources  entities  are  structured  in  a  way  that  all  proposed 
and  approved  BDF  units  will  share  the  BDF  job  dictionary,  BDF  salary  and  allowance 
tables,  and  BDF  vehicle  and  weapon  catalogs.  As  a  result,  this  will  minimize  redundancy 
of  information  and  make  the  database  run  more  efficiently  during  execution  of  the  DSS. 

2.  Physical  Design  of  BDFDSS 

The  database  schema  can  be  transfonned  to  the  relational  database  design  in  a 
desired  target  DBMS  which  in  our  case  will  be  MS  Access™.  MS  Access™  provides  the 
underlying  database  management  functions  and  features  needed  for  designing  the 
BDF  DSS.  The  relational  structure  diagram  of  the  BDF  DSS  and  the  properties  of  the 
relationships  are  depicted  in  Appendix  C.  In  the  relational  structure  diagram,  each  entity 
(relation)  in  the  ER  diagram  is  translated  to  a  table  which  has  a  primary  key  or  composite 
key  that  uniquely  identifies  each  row  (record)  in  that  table.  The  second  part  of  Appendix 
C  depicts  all  the  relationships  and  the  related  properties  established  between  the  tables. 


Visible  Systems  Coiporation  HXJCATIOHVIjTRAMNG  Vets  ion 

Prima  ry  Key  Level 


Figure  4.  Entity  Relationship  Diagram  of  the  Database  Model  -  Primary  Key  Level 
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3.  Process  Design  of  BDF  DSS 

Initially,  the  process  will  commence  when  POD  planners  want  to  compute  the 
fixed  and  recurring  cost  of  setting  up  a  BDF  unit  and  compare  it  with  other  existing  units. 
The  database  structure  enforces  the  referential  integrity  constraints  in  all  relationships  to 
assure  data  reliability.  Consequently,  the  data  model  requires  that  data  entry  sequentially 
follow  the  steps  outlined  below;  otherwise,  the  user  will  encounter  error  messages  from 
the  related  built-in  business  rule  if  a  precondition  of  data  entry  is  not  satisfied: 

a.  The  database  user  must  first  specify  the  unit  identification  number,  unit  type,  unit 
size,  and  whether  it  is  an  existing  BDF  unit  or  a  proposed  BDF  unit  (i.e.  101 
approved  artillery  battery,  104  approved  armor  battalion,  114  proposed  infantry 
brigade...  etc). 

b.  Before  building  the  unit  manpower,  all  jobs  that  are  required  in  the  new  BDF  unit 
must  first  be  in  the  BDF  job  dictionary.  In  other  words,  a  Job  Type  in  Jobs  table 
must  exist  first  in  order  to  add  the  same  JopType  in  Manpower  table. 

c.  Before  building  the  unit  manpower,  all  ranks  that  are  required  in  the  new  BDF 
unit  must  be  in  the  BDF  salary  table.  Similarly,  a  Rank  in  Salaries  table  must  exist 
first  in  order  to  add  the  same  Rank  in  Manpower  table. 

d.  Before  building  the  unit  vehicles  and  weapons,  all  vehicle  and  weapon  types  that 
are  required  in  the  new  BDF  unit  must  be  in  the  BDF  vehicle  and  weapon 
catalogs.  For  example,  a  VehicleType  in  Vehicle  table  must  exist  first  in  order  to 
add  the  same  VehicleType  in  Vehicle  Units  table. 

e.  Finally,  the  physical  design  enforces  two  important  relationship  properties  that  a 
BDF  DSS  user  must  be  aware  of  while  maintaining  the  data.  These  are  the 
cascade  update  related  fields  and  the  cascade  delete  related  records.  Cascade 
update  related  fields  allow  the  BDF  DSS  users  to  update  primary  key  fields  in  a 
parent  table  and  automatically  update  all  related  fields  in  associated  child  tables. 
Cascade  delete  related  records  will  delete  all  child  records  once  their  parent 
record  has  been  deleted. 

In  addition,  the  database  has  many  capabilities  that  fulfill  the  BDF  DSS 
requirements  which  are  stated  in  the  system  analysis  phase.  For  instance,  the  database  can 
instantly  compute  the  unit  statistics  based  on  hidden  equations  built-in  via  database 
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macros  once  a  modification  to  the  unit  resources  occurs.  When  the  application  user 
modifies  a  unit  weapon  record  for  example,  subsequent  changes  will  occur  in  the  unit 
record  for  both  Weapon  Total  Cost  and  Weapon  Maintenance  Cost  fields.  However,  this 
process  will  only  be  allowed  through  the  BDFDSS  analysis  menu  that  manipulate 
proposed  unit  structures  to  generate  more  scenarios  and  at  the  same  time  avoid  alterations 
on  existing  unit  structures. 

The  second  component  in  designing  a  DSS  is  to  develop  the  analytical  models 
that  will  be  utilized  in  the  BDF  DSS.  In  the  next  chapter,  we  will  introduce  two  examples 
of  applications  of  optimization  models  which  comply  with  the  performance  metrics 
described  in  earlier  chapter.  The  chapter  will  cover  the  construction  cycle  of  each  model 
and  explain  it  step  by  step. 
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IV.  THE  OPTIMIZATION  MODELS 


A.  INTRODUCTION 

Our  world  is  filled  with  limited  resources.  The  amount  of  oil  we  can  pump 
out  of  the  earth  is  limited.  The  amount  of  land  available  for  garbage  dumps  and 
hazardous  waste  is  limited  and,  in  many  areas,  diminishing  rapidly.... Deciding 
how  best  to  use  the  limited  resources  available  to  an  individual  or  a  business  is  a 
universal  problem.  In  today’s  competitive  business  environment,  it  is  increasingly 
important  to  make  sure  that  a  company’s  limited  resources  are  used  in  the  most 
efficient  manner  possible.  Typically,  this  involves  determining  how  to  allocate  the 
resources  in  such  a  way  as  to  maximize  profits  or  minimize  costs.  [Ref.  4.  Sect. 
2.0-16] 

Mathematical  prograimning  (MP)  is  part  of  a  larger  field  of  management  science 
called  operations  research  that  finds  the  optimal,  or  most  efficient,  way  of  using  limited 
resources  to  achieve  the  objectives  of  an  individual  or  a  business.  For  this  reason, 
mathematical  prograimning  is  often  referred  to  as  optimization.  [Ref.  5] 

Optimization  covers  a  broad  range  of  problems  that  share  a  common  goal,  namely 
determining  values  for  decision  variables  in  a  problem  that  will  maximize  (or  minimize) 
some  objective  functions  while  satisfying  various  constraints.  Constraints  impose 
restrictions  on  the  values  that  can  be  assumed  by  the  decision  variables  and  define  the  set 
of  feasible  options  (or  the  feasible  region)  for  the  problem.  Accordingly,  the  linear 
programming  (LP)  problem  represents  a  special  category  of  MP  problems  in  which  the 
objective  function  and  all  the  constraints  can  be  expressed  as  linear  combinations  of  the 
decision  variables.  [Ref.  6] 

This  chapter  will  present  two  optimization  models  which  will  be  part  of  the 
BDFDSS.  These  models  are  essential  for  the  required  DSS  in  order  to  satisfy  the  cost 
and  quality  perfonnance  metrics  described  in  chapter  2.  This  chapter  also  explains  in 
detail  how  to  create  and  maintain  optimization  models  that  support  BDF  decision-makers. 


B.  INFANTRY  BATTALION  MODEL 

Before  describing  this  model,  we  will  first  implement  a  general  form  of  the 
problem-solving  process  in  order  to  best  understand  and  visualize  how  modeling  fits  into 
the  entire  BDF  DSS  problem.  [Ref.  7]  As  shown  in  Figure  4  below,  the  problem-solving 
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process  consists  of  five  major  steps.  For  each  step  below,  we  will  describe  the  BDF- 
specific  circumstances  which  are  relevant  and  the  appropriate  sub-processes  which 
comprise  it  if  any. 


Figure  5.  Visual  Model  of  the  Problem-solving  Process  (From  Ref  4) 

1.  Identify  Problem 

The  BDF  wants  to  optimize  its  budget  when  establishing  or  maintaining  a  unit 
structure  that  has  associated  resources  and  costs.  At  the  same  time,  BDF  also  wants  to 
make  that  unit  structure  as  effective  as  possible  so  that  it  will  produce  at  maximum 
throughput.  The  first  BDF  demand  emphasizes  the  cost  performance  metric  of  the  unit 
structure,  whereas  the  second  one  focuses  on  the  quality  performance  metric  of  the  unit 
structure  (see  chapter  2).  As  a  result,  we  can  precisely  define  the  BDF  problem  as 
follows:  “BDF  wants  to  achieve  simultaneously  a  cost-effective  and  high  quality  unit 
structure  which  respectively  captures  efficiency  and  effectiveness  measures  of  the  unit 
structure.” 

2.  Formulate  and  Implement  the  Optimization  Model 

The  fonnulation  process  is  better  described  as  “brainstorming  the  model”.  We  will 
create  the  manpower  optimization  model  of  the  infantry  battalion  step  by  step  as  follows: 

a.  Defining  the  Decision  Variable 

The  decision  variables  that  we  wish  to  compute  are  the  numbers  of  all 
ranks  required  in  an  infantry  battalion  structure.  Therefore,  we  can  refer  to  the  ranks  with 
the  equivalent  military  standard  symbols  as  the  following: 
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0 1  refers  to  #  of  2nd  Lieutenant  Officer 

02  refers  to  #  of  1 st  Lieutenant  Officer 

03  refers  to  #  of  Captain  Officer 

04  refers  to  #  of  Major  Officer 

05  refers  to  #  of  Lt  Colonel  Officer 

06  refers  to  #  of  Colonel  Officer 

E7  refers  to  #  of  Warrant  officer  (Enlisted  rank) 

E6  refers  to  #  of  2nd  Warrant 
E5  refers  to  #  of  Sergeant  Major 
E4  refers  to  #  of  Sergeant 
E3  refers  to  #  of  Corporal 
E2  refers  to  #  of  Lance  Corporal 
El  refers  to  #  of  Private  Soldier 
CIV  refers  to  #  of  Civilians 

b.  Defining  the  Objective  Function 

The  objective  function  is  to  maximize  the  total  number  of  ranks 
(optimized  ranks)  subject  to  the  maximum  budget  that  the  BDF  can  afford.  The  budget 
ceiling  will  be  the  first  restriction  included  in  the  constraints  part.  Therefore,  the  objective 
function  is: 


Maximize:  0 1 +02+03+04+05+06+E 1 +E2+E3+E4+E5+E6+E7+CIV 


c.  Defining  the  Constraints 

Several  types  of  constraints  affect  this  model. 


Budget  Constraint:  BDF  will  estimate  the  maximum  budget  that  it  can 
afford  to  establish  an  infantry  battalion  when  it  determines  the  average  spending  on 
existing  similar  unit  structures.  We  will  name  the  estimated  maximum  budget  as  T  which 
is  an  input  field  (user-defined).  We  obtain  the  optimized  total  annual  salary  for  the 
infantry  battalion  by  multiplying  the  number  of  each  rank  (optimized  rank)  and  the 
correspondent  monthly  basic  salary  by  12,  and  then  summing  these  values.  As  shown  in 
the  formula  below,  the  constraint  is  that  the  optimized  total  annual  salary  should  be  less 
or  equal  to  the  estimated  maximum  budget  (T). 

[(06*4500)  +  (05*4000)  +  (04*3500)  +  (03*3000)  +  (02*2500)  + 

(01*2000)  +  (E7*1500)  +  (E6*1300)  +  (E5*1100)  +  (E4*900)  +  (E3*700)  + 
(E2*500)  +  (El *400)  +  (CIV*300)]  *  12  <=  T 
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Default  Constraints:  Certain  ranks  in  the  BDF  must  be  allocated  exactly, 

either  by  default  according  to  BDF  regulations.  Additionally,  the  user  can  define  those 

values  dynamically  to  override  the  BDF  defaults.  Those  are  as  follows: 

06=1  (#  of  C0L=1) 

05  =  6  (#  of  LTC=6) 

04  =  14  (#  of  MAJ=14) 

E7  =  7  (#  of  WAR=7) 

Budget  Allocation  Constraints:  This  type  of  constraint  will  divide  the 
optimized  total  annual  salary  into  officer  (OS  or  officers  salaries),  enlisted  (ES  or  enlisted 
salaries),  and  civilian  (CS  or  civilian  salaries)  groups  to  be  matched  with  user-defined 
percentages.  The  percentages  will  be  automatically  multiplied  by  the  estimated  maximum 
budget  (T)  which  will  then  correspond  to  the  maximum  budget  allocation  to  each  group. 
As  stated  in  the  formula  below,  for  each  group,  the  constraint  is  that  the  group  optimized 
total  annual  salary  should  not  be  greater  than  the  corresponding  maximum  allocation  of 
the  budget. 

0S<=  20%  of  T 
ES<=  78%  of  T 
CS<=  02%  of  T 

Manpower  Allocation  Constraints:  Similar  to  the  budget  allocation 
constraints,  this  constraint  separates  the  optimized  total  ranks  into  officer  (OM  or  officers 
manpower)  and  enlisted  plus  civilian  (ECM)  groups  to  be  matched  with  user-defined 
percentages.  In  the  first  case,  a  percentage  of  4%  will  be  automatically  multiplied  by  the 
optimized  total  ranks  which  should  be  less  than,  or  equal  to,  the  optimum  number  of 
officer  ranks.  In  the  second  case,  a  percentage  of  96%  will  be  automatically  multiplied  by 
the  optimized  total  ranks  which  should  be  greater  or  equal  than  the  optimum  number  of 
enlisted  plus  civilian  ranks.  These  two  percentages  will  be  user-specified  to  allow 
flexibility  in  the  model. 

OM  >=  04%  of  Manpower  (4%  of  the  total  optimized  manpower) 

ECM  <=  96%  of  Manpower  (96%  of  the  total  optimized  manpower) 
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Upper  and  Lower  Boundary  Constraints:  This  set  of  constraints  will  force 

the  rank  numbers  to  be  shaped  as  a  pyramid  in  which  they  obey  one  of  the  perfonnance 

measures  stated  in  chapter  2.  For  the  enlisted  infantry  battalion  ranks,  we  wish  to  separate 

adjacent  ranks  from  each  other.  For  example,  the  number  of  the  E6  rank  must  be  at  least 

two  times  that  of  the  number  of  the  E7  rank  which  is  a  user-specified  parameter  and  not 

more  than  four  times  that  of  the  E7.  However,  we  can  set  the  upper  bound  only  for  the 

last  rank,  El,  to  be  not  more  than  four  times  that  of  E2  because  we  do  not  know  how 

much  will  be  left  from  the  budget  to  cover  the  last  rank.  Additionally,  to  meet  the  BDF 

default  in  distributing  the  lowest  officer ’s  ranks,  we  presumed  that  the  number  of  01  is 

less  or  equal  than  the  number  of  02  and  the  number  of  02  is  less  or  equal  than  the 

number  of  03.  Thus,  for  an  infantry  battalion,  we  set  the  upper  bound  factor  to  be  4  and 

the  lower  bound  factor  to  be  2  as  seen  in  the  equations  below. 

2*E7  <=  E6  <=  4*E7  (i.e.  for  E7=7  then  14<=E6<=28) 

2*E6  <=  E5  <=  4*E6 
2*E5  <=  E4  <=  4*E5 
2*E4  <=  E3  <=  4*E4 
2*E3  <=  E2  <=  4*E3 
El  <=  4*E2 
01  <=  02 
02  <=  03 

Integrality  conditions:  We  must  embed  this  constraint  to  ensure  integer 
values  and  avoid  fractions  in  all  of  the  optimized  ranks.  Besides,  all  ranks  must  be  greater 
than  zero  to  obtain  nonnegative  solutions.  Clearly,  this  is  an  integer  programming  model 
strictly  speaking,  rather  than  a  linear  programming  model,  although  one  can  do  away 
with  the  integer  constraints  and  just  round  (up  or  down)  the  resultant  values  to  the  nearest 
whole  number  in  order  to  utilize  as  much  as  possible  of  the  allocated  budget  (T).  The 
constraint  is  as  follow: 

All  ranks  are  Integer  and  >=0 

d.  Implement  the  Model 

Having  identified  the  problem  and  formulated  the  model,  we  turn  our 
attention  to  implementing  the  model.  We  have  selected  MS  Excel  to  present  our  model 
since  it  is  the  most  popular  spreadsheet  application  and  it  is  widely  available.  Appendix 
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D  shows  the  model  and  the  generated  reports  related  to  the  model.  To  get  a  reliable, 
auditable  and  modifiable  spreadsheet  design,  we  followed  the  guidelines  stated  in  the 
Spreadsheet  Modeling  and  Decision  Analysis  textbook.  [Ref.  4]  Briefly,  these  guidelines 
are  as  follows: 

1)  Organize  the  data,  then  build  the  model  around  the  data. 

2)  Do  not  embed  numeric  constants  in  formula. 

3)  Things  which  are  logically  related  (e.g.,  left-hand  sides  and  right-hand 
sides  of  constraints)  should  be  arranged  in  close  physical  proximity  to  one 
another  and  in  the  same  columnar  or  row  orientation. 

4)  A  design  that  results  in  formulas  that  can  be  copied  is  probably  better  than 
one  that  does  not. 

5)  Column  or  row  totals  should  be  in  close  proximity  to  the  columns  or  rows 
being  totaled. 

6)  The  English-reading  human  eye  scans  left  to  right,  top  to  bottom. 

7)  Use  color,  shading,  borders  and  protection  to  distinguish  changeable 
parameters  from  other  elements  of  the  model. 

8)  Use  text  boxes  and  cell  comments  to  document  various  elements  of  the 
model. 

3.  Analyze  the  Model 

After  verifying  that  the  spreadsheet  model  has  been  implemented  accurately  as 
illustrated  in  Appendix  D,  the  next  step  in  the  problem-solving  process  is  to  check  that 
the  model  is  doing  exactly  what  it  was  designed  to  do  (i.e.  the  optimized  values  are 
always  within  the  constraints  that  have  been  specified).  The  main  focus  of  this  step  is  to 
generate  and  evaluate  alternatives  that  might  lead  to  the  best  solution  of  the  problem.  This 
involves  playing  out  a  number  of  scenarios  or  asking  several  “What  if’  questions. 
Spreadsheets  are  particularly  helpful  in  analyzing  mathematical  models  in  this  manner. 
Generally,  “What  if’  questions  imply  loosening  or  tightening  the  constraints,  adding 
more  constraints,  or  deleting  previous  constraints  as  needed.  However,  in  this  model,  it 
should  be  fairly  simple  to  change  some  of  the  assumptions  in  the  model  to  see  what  might 
happen  in  different  situations. 
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4.  Test  Results 

The  process  of  analyzing  a  model  does  not  always  provide  a  solution  to  the  actual 
problem  being  studied  as  in  our  case.  As  we  analyze  a  model  by  asking  various  “What  if’ 
questions,  it  is  important  that  a  BDFDSS  user  be  able  to  test  the  feasibility  and  quality 
of  each  potential  solution.  We  know  that  an  optimal  solution  derived  from  the  model  can 
exhibit  known  LP  problem  anomalies  (i.e.  more  than  one  solution  can  be  obtained,  and 
degeneracy,  the  condition  which  gives  different  interpretations  of  the  values  on  the 
sensitivity  report  that  cannot  be  relied  upon);  therefore,  the  BDF  DSS  user  must  know 
how  to  read  the  sensitivity  report  generated  by  Excel  in  order  to  see  how  sensitive  the 
solution  is  and  if  is  it  applicable  or  not.  [Ref.  8] 

Fortunately,  MS  Excel  provides  a  help  tool  to  assist  the  user  in  reading  the 
sensitivity  report  in  an  appropriate  way.  This  tool  is  called  the  Sensitivity  Assistant  Add¬ 
in  and  can  be  installed  by  copying  the  Sensitivity.xla  file  from  the  MS  Office  CD-ROM 
to  the  folder  on  the  hard  drive  that  contains  the  Solver.xla  (In  most  cases,  this  will  be  the 
folder  C:\Program  FilesYMicrosoft  Office\Office\Library\Solver).  [Ref.  4]  Then  by 
following  the  steps  below,  the  user  can  utilize  the  mentioned  tool  when  needed: 

a.  In  Excel,  click  Tools,  Add-Ins 

b.  Click  the  Browse  button. 

c.  Locate  the  Sensitivity.xla  file  and  click  OK. 

Therefore,  to  check  the  model  validity,  users  must  always  conduct  a  sensitivity 
analysis  about  the  model  assumptions  whether  they  reflect  reality  by  either  negotiating 
those  assumptions  with  the  domain  experts  and  decision  makers  of  BDF  or  comparing 
them  with  the  assumptions  of  similar  unit  structure  of  friendly  forces. 

5.  Implement  the  Solution 

The  last  step  of  the  problem-solving  process,  implementation  or  presentation,  is 
often  the  most  difficult.  In  other  words,  the  BDF  DSS  users  still  have  to  convince  the 
BDF  top  level  decision-makers  that  the  solutions  they  found  when  constructing  the 
proposed  unit  organizational  structure  are  worthy  of  implementation  in  the  real  world. 
The  BDF  DSS  users  can  always  use  the  visualization  tools  provided  in  the  BDF  DSS 
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application  (i.e.  charts  and  pivot  tables)  in  concert  with  the  optimization  models  when 
presenting  their  arguments.  Therefore,  a  well-organized  and  clear  presentation  to  the  BDF 
top  level  decision-makers  may  help  to  obtain  the  initial  approval  in  implementing  a  sound 
proposal  for  a  unit  structure. 

C.  ARMOR  BATTALION 

When  building  this  model,  we  followed  the  same  sequence  of  the  problem-solving 
process  used  in  the  previous  one.  However  to  avoid  redundancy,  we  will  address  only  the 
differences  that  occur  in  this  model.  The  steps  in  creating  the  Armor  battalion 
optimization  model  were  the  same  as  the  Infantry  battalion  except  for  the  following: 

1.  Identify  Problem 

The  BDF  goal  which  was  described  in  the  first  model  was  to  achieve  a  cost- 
effective  and  a  high  quality  BDF  unit  structure.  However,  we  have  assumed  that  the  BDF 
representatives  have  looked  at  the  first  model  and  their  feedback  question  has  been:  “Can 
we  achieve  more  quality  than  this?”.  Thus,  this  model  will  focus  upon  higher  quality  in 
the  unit  structure  which  is  one  of  the  major  performance  measures  that  impact  the 
structure  score  in  addition  to  the  structure  cost. 

2.  Formulate  and  Implement  the  Optimization  Model 

To  achieve  the  goal  of  obtaining  a  higher  quality  in  the  unit  structure,  we  have 
included  another  feature  in  this  model  to  attain  the  quality  needed.  As  explained  in 
chapter  2,  this  feature  is  to  include  the  BDF  unit’s  manpower  categories  in  the  BDF  DSS. 
Earlier,  we  said  that  those  manpower  categories  are  operation,  administrative,  and 
technical  positions  and  each  type  of  unit  has  certain  ranges  that  should  not  be  exceeded. 
Therefore,  this  model  will  be  a  second  version  of  the  first  which  handles  the  dilemma  of 
how  to  optimize  the  number  of  categories  necessary  in  the  unit  structure  along  with  other 
constraints  demonstrated  previously. 
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a.  Defining  the  Decision  Variable 

This  model  requires  more  decision  variables  since  we  set  apart  the 
manpower  into  three  groups.  Consequently,  we  will  multiply  the  14  different  ranks  as 
defined  in  the  infantry  battalion  structure  by  three  to  get  a  total  of  42  decision  variables  as 


shown  bellow: 

06  ranks  for  operation 
05  ranks  for  operation 
04  ranks  for  operation 
03  ranks  for  operation 
02  ranks  for  operation 
0 1  ranks  for  operation 
E7  ranks  for  operation 
E6  ranks  for  operation 
E5  ranks  for  operation 
E4  ranks  for  operation 
E3  ranks  for  operation 
E2  ranks  for  operation 
El  ranks  for  operation 
Civ  ranks  for  operation 


06  ranks  for  administration 
05  ranks  for  administration 
04  ranks  for  administration 
03  ranks  for  administration 
02  ranks  for  administration 
0 1  ranks  for  administration 
E7  ranks  for  administration 
E6  ranks  for  administration 
E5  ranks  for  administration 
E4  ranks  for  administration 
E3  ranks  for  administration 
E2  ranks  for  administration 
E 1  ranks  for  administration 
Civ  ranks  for  administration 


06  ranks  for  technical 
05  ranks  for  technical 
04  ranks  for  technical 
03  ranks  for  technical 
02  ranks  for  technical 
0 1  ranks  for  technical 
E7  ranks  for  technical 
E6  ranks  for  technical 
E5  ranks  for  technical 
E4  ranks  for  technical 
E3  ranks  for  technical 
E2  ranks  for  technical 
E 1  ranks  for  technical 
Civ  ranks  for  technical 


b.  Defining  the  Objective  Function 

The  Objective  function  is  to  maximize  the  total  number  of  ranks  including 
all  categories  (optimized  ranks)  to  as  the  extent  the  estimated  budget  (T)  allows.  In  other 
words,  this  objective  will  embrace  the  same  concept  of  the  infantry  battalion  model  in 
trying  to  use  as  much  of  the  allocated  budget  as  possible.  Therefore,  the  objective 
function  is: 

Maximize: 

[0 1 +02+03+04+05+06+E 1  +E2+E3+E4+E5+E6+E7+CIV]0ps  + 

[O 1 +02+03+04+05+06+E 1  +E2+E3+E4+E5+E6+E7+CIV]  Admin  + 
[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]iech 

c.  Defining  the  Constraints 

The  only  added  constraints  in  this  model  are  two  types  and  the  rest  were 
modified  accordingly.  Those  are  as  follow: 

Category  Constraint:  The  model  will  give  the  user  the  ability  to  assign  a 
range  of  certain  percentages  (user-specified  values)  of  the  total  manpower  to  each 
manpower  category  in  the  Annor  battalion.  This  means  that  each  category  of  the  required 
manpower  will  have  upper  and  lower  bounds  to  fit  in.  The  conditions  are: 
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[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]ops  >  70%  of  total  manpower 
[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]ops  <  80%  of  total  manpower 
[01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV]  Admin  >  3%  of  total  manpower 
[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]Admin<  10%  of  total  manpower 
[01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV]  Tech  >  5%  of  total  manpower 
[01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV]  Tech  <  16%  of  total  manpower 


Default  Constraints:  As  a  subsequent  constraint  to  the  category  restriction, 
this  condition  must  be  included  in  the  model  to  ensure  that  the  BDF  standards  in  the 
number  of  officer  ranks  in  each  category  will  not  be  violated.  Those  ranks  must  be 
exactly  defined  and  cannot  be  optimized  in  an  Armor  battalion  structure.  Those  defaults 
are  as  follow: 


06=  1  (as  operation  Colonel) 

05=  6  (5  as  operation  LTC,  and  1  as  Admin  LTC) 

04=  1 0  (8  as  operation  MAJ,  1  as  Admin  MAJ,  and  1  as  Tech  MAJ) 

03  are  neither  Admin  nor  Tech  C APT’s 

02  are  neither  Admin  nor  Tech  1st  LT’s 

01  are  neither  Admin  nor  Tech  2nd  LT’s 

E7  =  7  (will  remain  the  same  as  in  the  first  model) 


Upper  and  Lower  Boundary  Constraints:  This  set  of  constraints  follows 

the  same  notion  of  the  infantry  battalion,  except  that  the  upper  bound  factor  has  changed 

to  2.75  instead  of  4,  and  the  lower  bound  factor  has  changed  to  1.25  instead  of  2  as  seen 

in  the  equations  below.  This  was  done  because  the  Armor  battalion  requires  relatively  less 

manpower  than  the  infantry  battalion. 

1.25  *E7  <=  E6  <=  2.75*E7 

1.25  *E6  <=  E5  <=2.75*E6 

1.25  *E5  <=  E4  <=  2.75*E5 

1.25  *E4  <=  E3  <=  2.75*E4 

1.25  *E3  <=  E2  <=2.75*E3 
El  <=2.75*E2 
01  <=  02 
02  <=  03 


In  conclusion,  these  two  models  demonstrate  the  computer-based  tools  that  will 

be  linked  to  the  BDFDSS  in  order  to  enhance  the  decision-making  process  when 

creating  and  maintaining  the  BDF  organizational  structures.  The  purpose  of  the  Armor 

battalion  is  to  illustrate  that  the  model  could  be  more  complicated  if  additional  decision 

variables  were  added  to  meet  the  modified  objective  function  (see  Appendix  D). 
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Furthermore  in  the  last  chapter,  we  will  suggest  a  few  points  regarding  modeling  that  will 
help  to  improve  this  capability  in  the  BDFDSS. 

Meanwhile,  the  last  part  in  designing  a  DSS  is  the  DSS  user  interface  that  allows 
the  user  to  access  the  internal  components  of  the  DSS  in  a  relatively  easy  fashion  and 
without  having  to  know  specifically  how  everything  is  put  together  or  how  it  works 
together.  The  last  set  of  appendixes  in  this  research  will  briefly  describe  each  part  of  the 
user  interface  prototypes  which  are  supported  with  figures.  The  appendixes  will  illustrate 
the  following: 

1 .  Appendix  E:  Program  control  diagrams 

2.  Appendix  F:  Prototype  of  input/output  forms 

3.  Appendix  G:  Prototype  of  queries 

4.  Appendix  H:  Prototype  of  reports 

5.  Appendix  I:  Prototype  of  analysis  forms 

6.  Appendix  J:  Brief  Users’  Manual 
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V.  THE  USER  INTERFACES 


A.  INTRODUCTION 

The  user  interface,  the  last  component  in  designing  a  DSS,  is  one  of  the  most 
important  parts  of  any  program  because  it  determines  how  easily  you  can  make  the 
program  do  what  you  want.  A  powerful  program  with  a  poorly  designed  user  interface 
has  little  value.  Also,  graphical  user  interfaces  (GUIs)  that  use  windows,  icons,  and  pop¬ 
up  menus  have  become  standard  on  today’s  computer  systems.  [Ref.  9] 

Therefore  and  as  proof  of  concept,  we  will  demonstrate  in  this  chapter  a  specific 
use  case  scenario,  namely,  building  a  new  unit  and  how  the  DSS  user  would  evaluate  it 
through  the  BDFDSS  user  interface  capabilities.  In  this  case  study,  we  will  presume  that 
the  BDF  wants  to  establish  a  new  infantry  battalion  besides  the  two  existing  ones  they 
have  right  now  (101  and  103).  Additionally,  this  new  unit  has  an  initial  structure  depicted 
on  paper  and  has  not  been  entered  in  the  BDF  DSS  yet.  Basically,  we  will  tackle  the 
BDF  DSS  user  interface  functionalities  into  two  stages: 

1 .  Data  entry  and  editing  stage 

2.  Analysis  and  rebuilding  proposals  stage. 

B.  DATA  ENTRY  AND  EDITING  STAGE 

The  user  would  first  enter  the  preliminary  structure  of  the  new  unit  in  the 
BDF  DSS  and  give  it  a  unique  id  number  to  be  referred  to  later,  as  shown  in  Figure  6 
below. 


Figure  6.  “Add  new  unit”  Form 
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By  clicking  on  the  “Save  Record”  button,  the  user  has  entered  a  new  proposed 
infantry  battalion  in  the  system.  Then,  to  attach  the  manpower  resources  to  that  unit,  the 
user  needs  to  return  to  the  “Forms”  menu  and  click  on  the  “Add  new  jobs  to  a  unit” 
button  that  will  popup  the  manpower  data  entry  form  as  shown  in  Figure  7  below.  As 
long  as  the  manpower  required  for  this  unit  are  in  the  BDF  job  dictionary  (job  table),  the 
user  will  insert  the  unit  manpower  records  using  this  form;  otherwise  the  user  needs  to 
insert  those  jobs  first  into  the  job  table.  Similarly,  to  attach  the  vehicles  and  weapons 
resources  to  that  unit,  the  user  needs  to  select  “Add  new  vehicles  to  a  unit”  or  “Add  new 
weapons  to  a  unit”  in  the  “Forms”  main  menu,  and  follow  the  same  procedure  as  for 
attaching  unit  manpower. 


Figure  7.  “Add  new  jobs  to  a  unit”  Form 


Having  entered  the  new  unit  structure  in  the  BDF  DSS,  the  user  now  can  edit  all 
records  related  to  that  unit  via  the  “Modify”  part  of  “Forms”  main  menu.  For  instance, 
the  user  can  make  necessary  corrections  in  unit  905  vehicles  by  clicking  on  the  “Modify 
vehicles  on  a  unit”  button  as  shown  on  Figure  8  below.  To  speed  up  this  process,  the  user 
must  filter  unit  905  vehicles  from  other  unit  vehicles  by  using  the  “Filter  by  form”  icon 
which  is  the  third  one  in  the  tool  bar  list. 
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Figure  8.  “Modify  vehicles  in  a  unit”  Fonn 


Alternatively,  if  the  BDFDSS  already  has  a  similar  unit  type,  the  user  can  utilize 
the  built-in  system  tool  called  “Copy  any  unit  as  a  proposed  unit”  to  rapidly  enter  the  new 
unit  905  and  its  resources  in  the  BDF  DSS.  This  capability  as  shown  in  Figure  9  below  is 
found  in  the  Analysis  main  menu  which  will  be  widely  used  in  analyzing  proposals  that 
requires  generating  unit  scenarios  function.  After  this  step,  the  user  can  make  small 
modifications  to  unit  905  resources  to  match  the  initial  structure. 


0  Microsoft  Access 


Exit  3  WindowHide  3  WmowUnhide 


ype  a  question  for  help  * 


01  Copying — 


J*j 


Select  the  Unit  ID  you  wish  to  copy  flOl  j] 

Enter  a  new  Unit  ID  for  that  unit  |905| 

Copy  |  Cancel  | 

Figure  9.  “Copy  any  unit  as  a  proposed  unit”  Form 
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C.  ANALYSIS  AND  REBUILDING  PROPOSALS  STAGE 

At  this  stage,  the  user  can  compare  the  905  unit  structure  to  similar  existing  ones 
by  viewing  a  query  available  in  the  “Queries”  main  menu  as  shown  in  Figure  10  below. 
However,  this  figure  depicts  unit  statistics  only  and  does  not  give  explanations  about 
differences  among  similar  unit  type  structures.  Therefore,  other  queries  can  be  used  to 
view  unit  resource  differences  as  shown  in  Figure  1 1  below. 

HE 

«  <  ►  mil 


Figure  10.  “Query  units”  Fonn 


T ype  a  question  for  help  jj 


Datasheet  View 


Figure  1 1 .  “Compare  two  units  by  jobs”  Crosstab  Query 
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Moreover,  the  user  can  see  the  impact  of  unit  905  on  the  overall  BDF  existing 
units  (101,  102,  and  103  in  this  case)  as  illustrated  in  Figure  12  below.  This  screen 
utilizes  the  chart  capability  in  the  BDF  DSS  application  that  shows  only  the  unit  cost 
drivers  such  as  unit  annual  salary,  vehicle  maintenance  cost  for  this  year,  and  vehicle  total 
cost  for  each  unit.  However,  the  user  can  use  other  visualization  tool  like  pivot  tables  to 
see  numbers  and  grand  totals  among  those  units  as  shown  in  Figure  13  below.  The  chart 
and  pivot  tables’  tools  are  available  in  the  application  forms  and  queries  which  allow  the 
user  to  drill,  slice  and  dice,  and  change  displays  in  the  desired  measures  and  dimensions. 


Figure  12.  3-D  Chart  of  Unit  905  and  All  Other  Existing  BDF  Units 
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P~  ffi  J  ^  ID  j  Gf*  *  (?), 


Drop  Filter  Fields  Here 


Drop  Column  Fields  Here 
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Sum  ofTotal  annual  salaries 

Sum  of  Vehicle  Maint  cost  this  year  Sum 

of  Vehicle  Total  cost 

H  Existing  units 

101 

+ 

2176% 

38  09% 

27  22% 

102 

+ 

33.54% 

15.34% 

37.39% 

103 

+_ 

25.74% 

45  33% 

34.08% 

Total 

+ 

81.04% 

98  76% 

98  69% 

BThe  proposed  unit 

905 

+. 

18  96% 

1.24% 

1  31% 

Total 

+ 

18  96% 

1.24% 

1.31% 

Grand  Total 

+. 

100.00% 

100.00% 

100  00% 

Figure  13.  Pivot  Table  of  Unit  905  and  All  Other  Existing  BDF  Units  in  Percentages 
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Most  of  the  time,  the  user  gets  feedback  from  BDF  officials  about  the  manpower 
budget  constraint.  Hypothetically,  we  will  presume  that  the  HR  budget  constraint  of 
building  unit  905  is  $6,000,000  (at  least  20%  less  than  the  annual  salary  of  unit  101  and 
103  infantry  battalions).  Thus,  the  user  can  use  the  built-in  HR  optimization  models  to 
figure  out  the  best  rank  distribution  within  this  constraint  and  others  as  described  in 
earlier  chapter.  Thus,  as  shown  in  Figure  14  below,  the  user  can  select  the  Optimization 
model  submenu  from  the  “Analysis”  main  menu  and  then  click  on  the  “Infantry 
Battalion”  icon  that  matches  the  unit  905  type  and  start  to  play  different  scenarios.  As 
shown  on  Figure  15  below,  we  assume  that  the  user  has  run  different  scenarios  and 
“what-if  ’  questions  and  found  that  solution  as  the  most  reasonable  option  to  the  problem 
at  hand. 


^jnjxj 

Exit  3  WindowHide  3  Winowllnhide 

1  Type  a  question  for  help  M 

Optimization  models 

WJ 

m 

'infantry  Battalion  1 

Armor  Battalion.xls 

Return  to  Analysis  | 

Figure  14.  Optimization  Models  Submenu 


Figure  15.  MS  Excel  spreadsheet  of  the  Infantry  Battalion  HR  Model 
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After  assuring  that  this  is  the  best  solution  and  the  decision  variables  reflect 
reality  for  the  required  structure,  the  user  can  rebuild  the  unit  905  based  on  the  values  that 
will  represent  unit  905  manpower  requirements.  Ultimately,  the  user  will  see  that  all 
constraints  set  in  the  previous  model  are  verified  automatically  by  the  system  as  depicted 
in  Figure  16  below.  Additionally,  the  user  can  view  more  details  on  unit  905  as  seen  in 
Figure  17  below. 


Figure  16.  “View  proposed  units”  Form 
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Figure  17.  “More  details”  Form 


In  conclusion,  this  chapter  has  briefly  illustrated  the  BDF  DSS  user  interfaces 
through  a  case  study  that  requires  building  a  new  infantry  battalion  (905).  However,  the 
last  group  of  the  appendixes  show  more  examples  of  user  interfaces  as  well  as  provide  a 
brief  users’  manual. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

This  thesis  designed  and  developed  a  DSS  prototype  that  integrated  relational 
database  with  optimization  models  to  analyze  organizational  problems  arising  in  the 
BDF.  Initially,  we  described  the  current  processes  for  maintaining  the  BDF  organizational 
structures  in  order  to  justify  the  BDF  needs  for  a  computer-based  system  in  this  area.  In 
addition,  the  significant  parameters  that  must  be  taken  into  consideration  while 
processing  the  BDF  structures  were  identified  in  order  to  measure  a  structure’s  validity 
and  feasibility. 

The  thesis  then  presented  the  DSS  design  phase;  which  involved  the  development 
of  a  database  application.  The  data  element  of  the  DSS  was  discussed  in  three  stages:  the 
conceptual  data  model,  the  physical  design,  and  the  process  design.  The  required  system 
capabilities  were  incorporated  in  the  system  design  phase:  the  visualization  tools  and 
analytical  models. 

Next,  the  research  introduced  two  examples  of  optimization  models  that  are 
linked  to  the  BDFDSS  database.  The  performance  metrics  discussed  in  an  earlier 
chapter  were  embedded  in  the  models’  design  to  reflect  the  supportability  of  the  system. 
Generally,  the  two  examples  were  an  attempt  to  satisfy  the  BDF  requirements  in 
articulating  resource-planning  problems  to  find  the  best  options  among  the  many 
scenarios. 

Finally,  to  complete  the  creation  of  the  required  BDF  DSS,  the  last  part  of  the 
thesis  was  dedicated  to  the  user  interfaces  which  are  shown  in  the  related  appendixes. 
Furthermore,  a  brief  user’s  manual  was  provided  at  the  end  of  the  research  to  help  real 
decision-makers  use  the  system. 

B.  BDF  DSS  BENEFITS 

As  a  result  of  this  work,  BDF  can  obtain  several  benefits  when  implementing  the 
DSS  tool  prototyped  in  this  research: 
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1.  DSS  users  can  easily  analyze  the  effectiveness  of  BDF  organizational  structures 
with  less  effort  and  in  a  shorter  time.  With  this  DSS  tool,  users  can  approximately 
achieve  50%  time  savings  required  to  manipulate  the  BDF  organizational 
structures. 

2.  The  DSS  can  help  users  to  produce  evidence  in  support  of  a  decision  confinnation 
for  a  proposed  BDF  organizational  structure.  In  other  words,  these  decisions  are 
based  upon  data  and  analysis  instead  of  intuition  or  heuristic. 

3.  The  DSS  users  can  produce  a  wider  range  of  unit  structure  options  and  then  select 
the  most  appealing  ones  to  be  presented. 

4.  As  they  gain  experience  with  the  DSS,  DSS  users  can  develop  new  approaches 
when  thinking  about  a  problem  area  or  decision  context.  In  other  words,  the  DSS 
users  can  improve  their  ability  to  tackle  complex  unit  structures  as  time  passes. 

5.  Last  but  not  least,  the  suggested  decision  system  allows  for  careful,  analytical 
financial  planning.  This  means  that  the  DSS  users  can  easily  obtain  the  projected 
costs  of  the  BDF  structures,  which  gives  the  users,  and  the  BDF,  a  robust 
resource-planning  tool. 

C.  RECOMMENDATIONS 

A  future  study  of  this  topic  is  germane  to  the  BDF.  The  proposed  BDF  DSS  is 
sufficient  as  a  first  step  but  it  is  not  fully  operational  as  was  discussed  earlier.  The 
recommendations  for  a  future  research  in  this  field  are  summarized  as  follows: 

•  The  development  cycle  of  this  DSS  must  never  stop  whenever  a  system  update  is 
needed  to  meet  the  added  objectives. 

•  Beside  the  manpower,  vehicles,  and  weapons  resources,  the  DSS  must  include  all 
of  the  tangible  and  non-tangible  resources  needed  to  run  a  unit  structure  in  order 
to  give  the  decision-maker  a  complete  picture  of  the  unit  total  estimated  cost.  For 
instance,  tangible  resources  could  be  other  operational  equipment  that  is  not 
included  in  the  system  (i.e.  communication  equipment  and  weapon  ammunitions). 
Also,  non-tangible  resources  could  be  manpower-related  costs  such  as  training 
costs,  health  care  costs,  etc;  or  costs  related  to  the  unit  itself  such  as  a  unit’s 
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military  exercise  costs  and  unit  service  costs  such  as  electricity,  water  and  so 
forth. 

•  The  optimization  models  developed  in  this  system  can  be  further  remodeled  with 
more  valid  assumptions  to  accurately  reflect  reality. 

•  In  addition,  the  optimization  models  in  this  research  were  exclusively  considering 
the  HR  basic  salary  costs.  Thus,  other  HR  cost  drivers  such  as  allowances  can  be 
embedded  in  the  model  to  achieve  HR  cost  precision. 

•  A  more  robust  database  engine  must  be  considered  when  building  such  a  system 
to  speed  up  the  application  processing  time  and  to  accommodate  further  data 
expansion  and  features.  For  example,  Microsoft  SQL  Server  or  Oracle  databases 
can  house  and  process  larger  data  than  MS  Access™  does. 

•  With  regard  to  information  security  issue,  this  system  can  easily  be  transformed  to 
a  Web-based  system  using  the  Microsoft  Data  Access  Page  tool  (DAP)  in  order  to 
allow  decision-makers  to  remotely  present  their  models  and  data  from  anywhere. 

•  Finally,  the  optimization  model  in  this  system  can  be  extended  to  include  other 
model  types  such  as  forecasting  model.  Using  time  series  or  regression  methods, 
for  instance,  users  can  predict  BDF  manpower  end  strength  requirements  over  the 
next  3,  5,  10  years.  This  type  of  model  could  then  feed  the  related  optimization 
model. 

This  thesis  has  shown  a  useful  integration  of  database  and  optimization 
technology  that  can  potentially  help  solve  real  problems  in  the  BDF.  By  combining 
optimization  models  in  a  transparent  way  with  standard  database  management  tools,  a 
simple  yet  effective  decision  support  system  has  been  developed  to  evaluate  and  compare 
BDF  organizational  unit  structures.  The  benefits  of  this  system  underscore  the  value  of 
good  decision  support,  namely  more  decision  alternatives  can  be  evaluated  in  a  shorter 
amount  of  time. 
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APPENDIX  A:  ENTITY  RELATIONSHIP  DIAGRAMS  OF  BDF  DSS 


Visible  Systems  CoiporationHXJCAT10H4ljTRAININGVeision 

Prinia  ry  Key  Level 


Figure  18.  Entity  Relationship  Diagram  of  the  Database  Model  -  Primary  Key  Level 
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Visible  Systems  CotporationEDUCATlONAL'TRAINING  Version 


Attribute  Level 
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Figure  19.  Entity  Relationship  Diagram  of  the  Database  Model  -  Attribute  Level 
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APPENDIX  B:  DATABASE  SCHEMA  OF  BDF  DSS 


1.  RELATIONAL  MODEL 

Jobs  (JobType,  Description,  Service,  Category) 

Manpower  (UnitID  FK,  JobType  FK,  Rank  FK,  NumberofJobs, 
NumberofOccupiedJobs) 

Salaries  (Rank,  RankLevel,  BasicSalary,  YearlylncrementRate, 

TransportationAllowance,  SocialAllowance,  LivingAllowance/Y, 
ClothingAllowance/Y) 

Units  (UnitID,  ProposedUnit,  UnitType,  UnitSize,  BaseOccupiedJobs,  ManpowerSize, 

OffiserSize,  EnlistedSize,  Annualsalary,  OPS,  ADMIN,  TECH,  VehicleTotalCost, 
VehicleMaintCostThisY,  WeaponTotalCost,  WeaponMaintCostThisY, 
TransportationAllowance,  SocialAllowance,  LivingAllowance/Y, 
ClothingAllowance/Y,  OfficersSalary,  EnlistedCivilianSalary) 

UnitsVe hides  (VehicleType  FK,  UnitID  FK,  VehiclesQuantity) 

Units_Weapons  (WeaponType  FK,  UnitID  FK,  WeaponsQuantity) 

Vehicles  (VehicleType,  InitialCost,  ManufacturingCountry,  ProductionYear, 
MaintenanceRate,  Description) 

Weapons  (WeaponType,  InitialCost,  ManufacturingCountry,  ProductionYear, 
MaintenanceRate,  Description) 
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2.  GENERATED  DATABASE  SCHEMA 


CREATE  TABLE  Jobs 

( 

JobType 

Description 

Service 

Category 

); 


CHAR(20)  NOT  NULL, 
CHAR(400), 

CHAR(20), 

CHAR(20)  NOT  NULL 


CREATE  TABLE  Manpower 

( 

UnitID 

JobType 

Rank 

NumberofJobs 

NumberofOccupiedJobs 

); 


INTEGER  NOT  NULL, 
CHAR(20)  NOT  NULL, 
CHAR(20)  NOT  NULL, 
CHAR(20), 

INTEGER, 


CREATE  TABLE  Salaries 

( 

Rank 

RankLevel 

BasicSalary 

YearlylncrementRate 

Transporta  tionAllowance 

SocialAllowance 

LivingAllowance/Y 

ClothingAllowance/Y 

); 

CREATE  TABLE  Units 

( 

UnitID 

ProposedUnit 

UnitType 

UnitSize 

BaseOccupiedJobs 

ManpowerSize 

OffiserSize 

EnlistedSize 

Annualsalary 

OPS 

ADMIN 

TECH 

VehicleTotalCost 


CHAR(20)  NOT  NULL, 
CHAR(IO)  NOT  NULL, 
CHAR(20)  NOT  NULL, 
NUMBER  NOT  NULL, 
MONEY, 

MONEY, 

MONEY, 

MONEY 


INTEGER  NOT  NULL, 
BIT, 

INTEGER  NOT  NULL, 
CHAR(50)  NOT  NULL, 
BIT, 

INTEGER, 

INTEGER, 

INTEGER, 

CHAR(20), 

INTEGER, 

INTEGER, 

INTEGER, 

MONEY, 
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VehicleMaintCostThisY 

MONEY, 

WeaponTotalCost 

MONEY, 

WeaponMaintCostThisY 

MONEY, 

Transporta  tionAllowance 

MONEY, 

SocialAllowance 

MONEY, 

LivingAllowance/Y 

MONEY, 

ClothingAllowance/Y 

MONEY, 

OfficersSalary 

MONEY, 

EnlistedCivilianSalary 

MONEY 

CREATE  TABLE  Units  Vehicles 

( 

VehicleType  CHAR(50)  NOT  NULL, 

UnitID  INTEGER  NOT  NULL, 

VehiclesQuantity  INTEGER 

); 


CREATE  TABLE  Units  Weapons 


( 

WeaponType 

UnitID 

WeaponsQuantity 

); 

CREATE  TABLE  Vehicles 

( 

VehicleType 

InitialCost 

ManufacturingCountry 

ProductionYear 

MaintenanceRate 

Description 

); 

CREATE  TABLE  Weapons 

( 

WeaponType 

InitialCost 

ManufacturingCountry 

ProductionYear 

MaintenanceRate 

Description 

); 


CHAR(50)  NOT  NULL, 
INTEGER  NOT  NULL, 
INTEGER 


CHAR(50)  NOT  NULL, 
CHAR(20)  NOT  NULL, 
CHAR(20)  NOT  NULL, 
INTEGER  NOT  NULL, 
NUMBER  NOT  NULL, 
CHAR(400) 


CHAR(50)  NOT  NULL, 
CHAR(20)  NOT  NULL, 
CHAR(20)  NOT  NULL, 
INTEGER  NOT  NULL, 
NUMBER  NOT  NULL, 
CHAR(400) 
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CREATE  UNIQUE  INDEX  PKJobs  ON  Jobs  (  JobType  ASC  ); 

CREATE  UNIQUE  INDEX  PKManpower  ON  Manpower  (UnitID  ASC,  JobType  ASC,  Rank  ASC  ); 
CREATE  UNIQUE  INDEX  PKSalaries  ON  Salaries  (  Rank  ASC  ); 

CREATE  UNIQUE  INDEX  PKUnits  ON  Units  (  UnitID  ASC  ); 

CREATE  UNIQUE  INDEX  PKUnitsJVehicles  ON  UnitsJVehicles  (  VehicleType  ASC,  UnitID  ASC  ); 
CREATE  UNIQUE  INDEX  PKUnits_Weapons  ON  Units_Weapons  (  WeaponType  ASC,  UnitID  ASC  ); 
CREATE  UNIQUE  INDEX  PKVehicles  ON  Vehicles  (  VehicleType  ASC  ); 

CREATE  UNIQUE  INDEX  PKWeapons  ON  Weapons  (  WeaponType  ASC  ); 

ALTER  TABLE  Jobs  ADD 

CONSTRAINT  PKC  JobsOOOO  PRIMARY  KEY  (  JobType  ); 

ALTER  TABLE  Manpower  ADD 

CONSTRAINT  PKCJVIanpower0004  PRIMARY  KEY  (UnitID,  JobType,  Rank); 

ALTER  TABLE  Salaries  ADD 

CONSTRAINT  PKC_Salaries0005  PRIMARY  KEY  (  Rank  ); 

ALTER  TABLE  Units  ADD 

CONSTRAINT  PKC_Units0006  PRIMARY  KEY  (  UnitID  ); 

ALTER  TABLE  UnitsJVehicles  ADD 

CONSTRAINT  PKCJJnits JVehicles0009  PRIMARY  KEY  (  VehicleType,  UnitID  ); 

ALTER  TABLE  Units_Weapons  ADD 

CONSTRAINT  PKCJJnitsJWeaponsOOOC  PRIMARY  KEY  (  WeaponType,  UnitID  ); 

ALTER  TABLE  Vehicles  ADD 

CONSTRAINT  PKCJVehiclesOOOD  PRIMARY  KEY  ( VehicleType  ); 

ALTER  TABLE  Weapons  ADD 

CONSTRAINT  PKCJWeaponsOOOE  PRIMARY  KEY  (  WeaponType  ); 

ALTER  TABLE  Manpower  ADD 

CONSTRAINT  FKC  BelongsOOOl  FOREIGN  KEY  (  Rank  )  REFERENCES  Salaries; 

ALTER  TABLE  Manpower  ADD 

CONSTRAINT  FKC  Belongs0002  FOREIGN  KEY  (  JobType  )  REFERENCES  Jobs; 

ALTER  TABLE  Manpower  ADD 

CONSTRAINT  FKC_Contains0003  FOREIGN  KEY  (  UnitID  )  REFERENCES  Units; 

ALTER  TABLE  Units  Vehicles  ADD 
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CONSTRAINT  FKC_Is_Allocated_To0007  FOREIGN  KEY  ( VehicleType  )  REFERENCES 
Vehicles; 

ALTER  TABLE  UnitsJVehicles  ADD 

CONSTRAINT  FKC_Has0008  FOREIGN  KEY  (  UnitID  )  REFERENCES  Units; 

ALTER  TABLE  Units_Weapons  ADD 

CONSTRAINT  FKC_Is_allocated_ToOOOA  FOREIGN  KEY  (  WeaponType  )  REFERENCES  Weapons; 
ALTER  TABLE  Units_Weapons  ADD 

CONSTRAINT  FKC  HasOOOB  FOREIGN  KEY  (  UnitID  )  REFERENCES  Units; 


57 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


58 


APPENDIX  C:  RELATIONAL  DATABASE  DESIGN  OF  BDFDSS 

FROM  MS  ACCESS™ 


1.  RELATIONAL  STRUCTURE  DIAGRAM 


0  Microsoft  Access  -  [Relationships] 


File  Edit  View  Relationships  Tools  Window  Help 


Type  a  question  for  help 
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Figure  20.  MS  Access™  Relational  Structure  Diagram  of  BDF  DSS 
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2.  RELATIONSHIPS  PROPERTIES 


JobsManpower 


Jobs 

1  oo 

Manpower 

JobType 

JobType 

Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 

SalariesManpower 


Salaries 

1  oo 

Manpower 

Rank 

Rank 

Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 

UnitsManpower 


Units 

1  oo 

Manpower 

UnitID 
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RelationshipType:  One-To-Many 

UnitsUnits_Vehicles 


Units 
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UnitID 

UnitID 

Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 

UnitsUnits_Weapons 


Units 
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Units_Weapons 

UnitID 

UnitID 

Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 
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Vehicles 

1  oo 
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WeaponsUnits_Weapons 


Weapons 

1  oo 

Units_Weapons 

WeaponType 

WeaponType 

Attributes:  Enforced,  Cascade  Updates,  Cascade  Deletes 

RelationshipType:  One-To-Many 
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APPENDIX  D:  OPTIMIZATION  MODELS 


1.  INFANTRY  BATTALION 


Figure  2 1 .  Mathematical  Model  of  the  Infantry  Battalion 
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S  Microsoft  Excel  -  Infantry  Battabomds 


File  Edit  View  Insert  Format  Tools  Data  Window  Help 
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0 

223 
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Optimum  #  of  each  rank  CIV 

0 

33 
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Cell 

Name 
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Formula 

Status 

Slack 

$0$44 

Optimum  annual  salary  for  officers  (OS)  Optimum  solutions 

$1,200,000.00 

$0$44<=$l$44 

Binding 

0 

$0$45 

Optimum  annual  salary  for  enlisted  (ES)  Optimum  solutions 

$4,680,000.00 

$0$45<=$l$45 

Binding 

0 

$0$46 

Optimum  annual  salary  for  civilian  (CS)  Optimum  solutions 

$118,800.00 

$0$46<=$l$46 
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1200 

$K$54 

Optimum  #  of  each  rank  SGTM  (E5) 

28 
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28 
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56 
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0 

$J$54 
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14 

$J$54>=$J$36*$I$54 

Binding 

0 

$N$54 

Optimum  #  of  each  rank  LCPL  (E2) 

225 

$N$54<=$J$35*$M$54 

Not  Binding 

223 

$M$54 

Optimum  #  of  each  rank  CPL  (E3) 

112 

$M$54>=$J$36*$L$54 

Binding 

0 

$L$54 

Optimum  #  of  each  rank  SGT  (E4) 

56 

$L$54<=$J$35*$K$54 
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56 

$0$49 

Optimum  #  of  enlisted  &  civ  (ECM)  Optimum  solutions 
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$0$49<=$l$49 

Not  Binding 

0.88 

$J$54 

Optimum  #  of  each  rank  2ndWAR  (E6) 

14 
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Not  Binding 

14 

$K$54 
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28 
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Binding 

0 
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Not  Binding 
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$0$48 
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30.00 
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Binding 
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225 
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14 
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6 
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0 

$C$54 
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Not  Binding 
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$D$54 
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$E$54 
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14 
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Not  Binding 
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$L$54 

Optimum  #  of  each  rank  SGT  (E4) 

56 

$L$54>=0 

Not  Binding 

56 

$M$54 

Optimum  #  of  each  rank  CPL  (E3) 
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Not  Binding 

112 

$N$54 
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225 
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225 
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223 
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223 

$P$54 

Optimum  #  of  each  rank  CIV 
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33 
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Figure  24.  Implemented  Model  of  the  Annor  Battalion 
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0 

$N$57 

Optimal  TECH  LCPL  (E2) 

0 

2 

$0$57 

Optimal  TECH  PTE  (El) 

0 

48 

$P$57 

Optimal  TECH  CIV 

0 
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$Q$56 

Optimal  ADM  Total 

46 

$Q$56<=$0$42*$Q$58 

Not  Binding 

8.2 

$O$50 

Optimum  #  of  enlisted  &  civ  (ECM)  Operation 

504.00 

$0$50<=$l$50 

Not  Binding 

5.48 

$Q$57 

Optimal  TECH  Total 

85 

$Q$57<=$0$43*$Q$58 

Not  Binding 

1.72 

$0$45 

Optimum  annual  salary  for  officers  (OS)  Operation 
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$0$45<=$l$45 
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$0$46 
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$0$47 
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9 
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17 
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9 
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54 
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44 

$M$58<=$J$36*$L$58 

Binding 
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Total  SGTM  (E5) 

12 

$K$58>=$J$37*$J$58 
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$0$49 
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38.00 
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0.06 

$l$58 

Total  WAR  (E7) 

7 

$I$58=$D$42 

Not  Binding 

0 

$K$58 

Total  SGTM  (E5) 

12 

$K$58<=$J$36*$J$58 

Not  Binding 
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$Q$59 
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4,450,800 

$Q$59<=$D$36 

Not  Binding 

49199.99998 

$H$58 

Total  2ndLT  (01) 

7 

$H$58<=$G$58 

Binding 

0 
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Binding 
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Total  CPL  (E3) 

44 
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Not  Binding 
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Not  Binding 
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Not  Binding 
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Binding 
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48 

$P$57 

Optimal  TECH  CIV 

12 

$P$57>=0 

Not  Binding 

12 

$D$55 

Optimal  OPS  LTC  (05) 

5 

$D$55=$0$36 

Binding 

0 

$D$57 

Optimal  TECH  LTC  (05) 

0 

$D$57=$Q$36 

Binding 

0 

$C$55 

Optimal  OPS  COL  (06) 

1 

$C$55=$D$39 

Binding 

0 

$D$56 

Optimal  ADM  LTC  (05) 

1 

$D$56=$P$36 

Binding 

0 

$E$55 

Optimal  OPS  MAJ  (04) 

8 

$E$55=$0$37 

Binding 

0 

$E$56 

Optimal  ADM  MAJ  (04) 

1 

$E$56=$P$37 

Not  Binding 

0 

$E$57 

Optimal  TECH  MAJ  (04) 

1 

$E$57=$Q$37 

Binding 

0 

$F$56 

Optimal  ADM  CAPT  (03) 

0 

$F$56=$P$38 

Not  Binding 

0 

$F$57 

Optimal  TECH  CAPT  (03) 

0 

$F$57=$Q$38 

Not  Binding 

0 

$G$56 

Optimal  ADM  LT  (02) 

0 

$G$56=$P$39 

Binding 

0 

$G$57 

Optimal  TECH  LT  (02) 

0 

$G$57=$Q$39 

Binding 

0 

$H$56 

Optimal  ADM  2ndLT  (01) 

0 

$H$56=$P$40 

Not  Binding 

0 

$H$57 

Optimal  TECH  2ndLT  (01) 

0 

$H$57=$Q$40 

Binding 

0 

$C$55 

Optimal  OPS  COL  (06) 

1 

$C$55=integer 

Binding 

0 

$D$55 

Optimal  OPS  LTC  (05) 

5 

$D$55=integer 

Binding 

0 

$E$55 

Optimal  OPS  MAJ  (04) 

8 

$E$55=integer 

Binding 

0 

$F$55 

Optimal  OPS  CAPT  (03) 

7 

$F$55=integer 

Binding 

0 

$G$55 

Optimal  OPS  LT  (02) 

7 

$G$55=integer 

Binding 

0 

$H$55 

Optimal  OPS  2ndLT  (Ol) 

7 

$H$55=integer 

Binding 

0 

$l$55 

Optimal  OPS  WAR  (E7) 

6 

$l$55=integer 

Binding 

0 

$J$55 

Optimal  OPS  2ndWAR  (E6) 

0 

$J$55=integer 

Binding 

0 

$K$55 

Optimal  OPS  SGTM  (E5) 

0 

$K$55=integer 

Binding 

0 

$L$55 

Optimal  OPS  SGT  (E4) 

16 

$L$55=integer 

Binding 

0 

$M$55 

Optimal  OPS  CPL  (E3) 

43 

$M$55=integer 

Binding 

0 

$N$55 

Optimal  OPS  LCPL  (E2) 

107 

$N$55=integer 

Binding 

0 

Optimal  OPS  PTE  (El) 

196 

$0$55=integer 

Binding 

0 

$P$55 

Optimal  OPS  CIV 

8 

$P$55=integer 

Binding 

0 

$C$56 

Optimal  ADM  COL  (06) 

0 

$C$56=integer 

Binding 

0 

$D$56 

Optimal  ADM  LTC  (05) 

1 

$D$56=integer 

Binding 

0 

$E$56 

Optimal  ADM  MAJ  (04) 

1 

$E$56=integer 

Binding 

0 

$F$56 

Optimal  ADM  CAPT  (03) 

0 

$F$56=integer 

Binding 

0 

$G$56 

Optimal  ADM  LT  (02) 

0 

$G$56=integer 

Binding 

0 

$H$56 

Optimal  ADM  2ndLT  (01) 

0 

$H$56=integer 

Binding 

0 

$l$56 

Optimal  ADM  WAR  (E7) 

0 

$l$56=integer 

Binding 

0 

$J$56 

Optimal  ADM  2ndWAR  (E6) 

0 

$J$56=integer 

Binding 

0 

$K$56 

Optimal  ADM  SGTM  (E5) 

0 

$K$56=integer 

Binding 

0 

$L$56 

Optimal  ADM  SGT  (E4) 

0 

$L$56=integer 

Binding 

0 

$M$56 

Optimal  ADM  CPL  (E3) 

1 

$M$56=integer 

Binding 

0 

$N$56 

Optimal  ADM  LCPL  (E2) 

0 

$N$56=integer 

Binding 

0 

$0$56 

Optimal  ADM  PTE  (El) 

33 

$0$56=integer 

Binding 

0 

$P$56 

Optimal  ADM  CIV 

10 

$P$56=integer 

Binding 

0 

$C$57 

Optimal  TECH  COL  (06) 

0 

$C$57=integer 

Binding 

0 

$D$57 

Optimal  TECH  LTC  (05) 

0 

$D$57=integer 

Binding 

0 

$E$57 

Optimal  TECH  MAJ  (04) 

1 

$E$57=integer 

Binding 

0 

$F$57 

Optimal  TECH  CAPT  (03) 

0 

$F$57=integer 

Binding 

0 

$G$57 

Optimal  TECH  LT  (02) 

0 

$G$57=integer 

Binding 

0 

$H$57 

Optimal  TECH  2ndLT  (Ol) 

0 

$H$57=integer 

Binding 

0 

$l$57 

Optimal  TECH  WAR  (E7) 

1 

$l$57=integer 

Binding 

0 

$J$57 

Optimal  TECH  2ndWAR  (E6) 

9 

$J$57=integer 

Binding 

0 

$K$57 

Optimal  TECH  SGTM  (E5) 

12 

$K$57=integer 

Binding 

0 

$L$57 

Optimal  TECH  SGT  (E4) 

0 

$L$57=integer 

Binding 

0 

$M$57 

Optimal  TECH  CPL  (E3) 

0 

$M$57=integer 

Binding 

0 

$N$57 

Optimal  TECH  LCPL  (E2) 

2 

$N$57=integer 

Binding 

0 

$0$57 

Optimal  TECH  PTE  (El) 

48 

$0$57=integer 

Binding 

0 

$P$57 

Optimal  TECH  CIV 

12 

$P$57=integer 

Binding 

0 

Table  2 
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APPENDIX  E:  PROGRAM  CONTROL  DIAGRAMS 


Figure  25.  Main  Menu  Switchboard 


69 


B  Microsoft  Access 


Exit  Q  WindowHide  3  Winowllnhide 


=LPJ^ll 

Type  a  question  for  help  Hi 


Figure  26.  Forms  Switchboard 
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Figure  27.  Queries  Switchboard 
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E  Microsoft  Access 


^jn|x] 

Exit  2  WindowHide  2  WinowUnhide  IjBType  a  question  for  help 


Figure  28.  Reports  Switchboard 
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Figure  29.  Analysis  Switchboard 
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APPENDIX  F:  PROTOTYPE  OF  INPUT/OUTPUT  FORMS 


1.  INPUT  FORMS 


Figure  30.  “Add  new  unit”  Form 


Figure  3 1 .  “Add  new  job”  Form 
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Figure  32.  “Add  new  rank  with  salary  info”  Form 


M  Microsoft  Access 


y  v  &  %  m  «  zi  aI  m  <  ►  m 


JnJxJ 


Type  a  question  for  help 


Figure  33.  “Add  new  vehicle”  Form 
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Figure  34.  “Add  new  weapon”  Fonn 


Q  Microsoft  Access 


B  V  X  ^  m  «  £1 1!  M  <  ►  M 


Figure  35.  “Add  new  jobs  to  a  unit”  Form 
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E  Microsoft  Access 


Figure  36.  “Add  new  vehicles  to  a  unit”  Form 


Figure  37.  “Add  new  weapons  to  a  unit”  Form 
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2, 


OUTPUT  FORMS 


l»\.  ^islxj 

^  k  <  ►  h  ¥  D  i  . 


Figure  38.  “Modify  unit”  Form 


Figure  39.  “More  details”  Form  Based  on  #  of  Occupied  Jobs  (Actual  Manpower  Cost) 
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Figure  40.  “More  details”  Form  Based  on  #  of  Jobs  (Budgeted  Manpower  Cost) 


H!?lI^ziAU  M  i  ►  m  i$  |£  H 


Figure  41.  “Modify  job”  Form 
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E  Microsoft  Access 


JSlxJ 

y  7  n  i5  ^  ti  li  &  %  e,  ^  i<  <  ►  n  ^Di 


Figure  42.  “Modify  rank  with  salary”  Form 


y  Microsoft  Access 


-=JsJ-*l 


B  v  1  ^  zl  il  X  ^  6  °  M  4  ►  N  y  |jQ|  1  Type  a  question  for  help  • 


Figure  43.  “Modify  vehicles”  Form 
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0  Microsoft  Access 


-=JS]_x| 

B  '7  'Si  %=,  'K  zl  II  X  %  ©  «  M  <  ►  N  VQ  ■  -  pea  queston  for  help  , 


Figure  44.  “Modify  weapon”  Form 


IMl  I.J.IJ.! ’  ^|njx| 

«  M  <  ►  W  I*  H  ■  BT^i^uSTforh^gl 


Figure  45.  “Modify  jobs  in  a  unit”  Form 
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Figure  46.  “Modify  vehicles  in  a  unit”  Fonn 


Figure  47.  “Modify  weapons  in  a  unit”  Form 
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APPENDIX  G:  PROTOTYPE  OF  QUERIES 


1.  SINGLE-TABLE  QUERIES 


Figure  48.  “Units”  Query 


E  Microsoft  Access 


H  ?  1  I.  ^  zl  y  I  i  6  ‘T  M  <  ►  M  *  U  H  Type  a  duesfcon  for  help 


Figure  49.  “Jobs”  Query 
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E  Microsoft  Access 


JS|x] 

H  v*"  'll]  ^  zl  a!  ^8)  Hi  *°  M  *  ►  M  w  H  I]  ^j^^juesti«Hbulel^g| 


Figure  50.  “Salaries”  Query 


Figure  5 1 .  “Vehicles”  Query 
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Figure  52.  “Weapons”  Query 


S  Microsoft  Access 


y  '§]  Y~  ^  zi  aI  X  %  @1  'n  M  <  ►  M  v  |)Q|  U 


Figure  53.  “Manpower”  Query 
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Figure  54.  “Units_vehicles”  Query 


0  Microsoft  Access 


<  ►  nqui 


Figure  55.  “Units_weapons”  Query 
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2, 


MULTIPLE-TABLE  QUERIES 


E  Microsoft  Access 


M  4  ►  M  ttSj  U  B  Type  a  question  for  help 


Figure  56.  “Unit  manpower”  Query 


E  Microsoft  Access 


pJn|*J 


Type  a  question  for  help 


Figure  57.  “Unit  vehicles”  Query 
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Figure  58.  “Unit  weapons”  Query 


El  Microsoft  Access 


Q  V  1  zi  iU  %  6  °  M  <  ►  N  w  |U|  E  [Type a questior for  help  [ 


Figure  59.  “Job  in  units”  Query 
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Figure  60.  “Vehicles  in  unit”  Query 


y  Microsoft  Access 


Exit  3  WindowHide  3  Winowllnhide 


Type  a  question  for  help  ♦ 


BE  Query  weapon  in  units_Multiquery 


Weapon  type  9mm  PISTOL 


Description 


PERSONAL  WEAPON 


Initial  cos t/we a p o n [SfOO.OO 


Manufacrurins  country  UK 


Production  vearl  1999 


Maintenance  rate  6 


Unit 


Unit  ID  |  Unit  type 

Unit  size 

Weapon  total  cost 

Weapons  quantity 

► 

H®  Infantry 

Battalion 

S3  486  000  00 

2 

102  Signal 

Brigade 

$3,921,500.00 

3 

103  Infantry 

Battalion 

$14  365.500  00 

7 

901  Armor 

Brigade 

S3  921  500  00 

3 

904  Infantry 

Battalion 

$3  216  000.00 

2 

Record:  M  |  1 1  l 

►  |  m  |»#|  of  6 

Return  to  Queries  j 

Record:  H  |  <  1 1  8  ►  I  ►!  !►*!  of  20 


Figure  6 1 .  “Weapons  in  unit”  Query 
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CREATING  AND  VIEWING  USER’S  QUERIES 


Figure  62.  “Reminder  instructions”  Window 


Figure  63.  “New  query”  Window 


Tables/Queries 


its  by  Unit  type  and  size|  jJ 

Table :  Units_Weapons  +■ 

Table:  Vehicles 

Selected  Fields: 

Query:  Analysis_Compare  two  units 

Query:  Analysis_Compare  two  units  by  jt 
Query:  Analysis_Compare  two  units  by  v 
Query:  Analysis_Compare  two  units  by  y 
Query:  Analysis JJnit  based  manpower  q 
Query:  Analysis  Unit  based  vehicles  que  ▼ 

Cancel 


Figure  64.  “Simple  query  wizard”  Window 


□ 


Which  fields  do  you  want  in  your  query? 

You  can  choose  from  more  than  one  table  or  query. 


Tables/Queries 
iQuer,:  Analvsii 

Available  Fields: 


;  .Compare  all  uni  | 


Finish  | 


Figure  65.  “Selecting  the  new  query  fields”  Window 
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Simple  Query  Wizard 


What  title  do  you  want  for  your  query? 


That's  all  the  information  the  wizard  needs  to  create  your 
query. 

Do  you  want  to  open  the  query  or  modify  the  query's  design? 

Open  the  query  to  view  information. 

C  Modify  the  query  design . 


V  Display  Help  on  working  with  the  query? 


Cancel 


<  Back 


Next 


Finish 


Figure  66.  “Naming  the  new  query”  Window 


Figure  67.  “Opening  the  new  query”  Window 


Figure  68.  “Viewing  the  new  query”  Window 
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APPENDIX  H:  PROTOTYPE  OF  REPORTS 


1.  SAMPLE  REPORTS 


Figure  69.  “Unit  manpower  comparison”  Report 
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y  Microsoft  Access 


Page  Setup...  Q 

E’i  ,P 


^injxj 

Pype  a  question  for  help  * 


100% 


Close  Setup  W  ■  £]  ^iT]  »  [?J 


List  of  weapons  in  unit 


— 3 


List  of  weapons  in  Unit  1 01 


Unit  type 

Unit  size 

Weapon  type 

Initial 

cost/weapon 

Weapon 

s 

Desciiption 

Infantry 

Battalion 

Tow 

SI  00,000.00 

12 

Sniper  Rifle  7.62mm 

S5, 000.00 

C 

Sniper  Auto -Gun 

S8, 000.00 

2 

MK-19 

S20.X0.00 

13 

Med-Range  Auto  Gun 

S5.X0.00 

39 

M 16  (5.56mm) 

S1.X0.00 

609 

PERSONAL  WEAPON 

GPM  G 

5  1  0.000.00 

54 

GENERALPURPOSE  MACHINE 

GUN  (7.66MM) 

9mm  PISTOL 

S500.X 

2 

PERSONAL  WEAPON 

9mm  Auto-Gun 

S5.XO.OO 

14 

81  Hovitzer 

sso.xo.x 

6 

60  Howtzer 

S30.X0.X 

9 

IVeapons  total  cost:  $3,486,000.00 

Page:  i<  I  <  II  T  >  I  >i  |  


A 


ET 


Ready 


► 


Figure  70.  “List  of  weapons  in  unit”  Report 


2. 


CREATING  AND  VIEWING  USER’S  REPORTS 


Remember* 


Note:  You  can  build  your  own  report  based  on  all  Tables  and  Select  Queries  available  In  the  Database  by  clicking  the  above 
"Creat  my  report"  button.  If  you  want  to  view  your  own  Report's)  do  the  following: 

*  Click  on  the  "View  my  report's)"  button 
x  Click  OK  to  view  created  reports 

x  Duble  dick  on  the  Report  you  want  to  open 

*  Or  select  the  Report  you  wish  to  redesign  then  dick  on  Design  button 

*  When  done,  minimize  the  Database  Window  OR  dick  on  "Hide  Window"  button  in  the  tool  bar 


Figure  7 1 .  “Reminder  instructions”  Window 
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New  Report 


esign  View 


Report  Wizard 
AutoReport:  Columnar 
AutoReport:  Tabular 
Chart  Wizard 
Label  'Wizard 


Choose  the  table  or  query  where 
the  object's  data  comes  from: 


Analysis_Compare  all  units  b’ 
Analysis_Compare  two  units 
Analysis_Compare  two  units 
Analysis_Compare  two  units 


II 


Figure  72.  “New  report”  Window 


Figure  73.  “Starting  to  design  the  new  report”  Window 


Figure  74. 


“New  report  in  design  phase”  Window 
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Figure  75.  “Opening  the  new  report”  Window 


E  Microsoft  Access  -  [XX] 


a  File  Edit  View  lools  Window  Help 


d 


Close  Setup  W  »  [^| 


^jnjxj 

▼  _  (5  x 

- 3 


Report  1:  Existing  units  statistics 

UnitID  Annual  salary  Transportation  Social  Living  Gothrng  Vehicles  total  Vehicle  maint  Weapons  total  Weapon  maint 

allowance  allon  ajice  allowance/!'  allow ance/Y  cost  cost  this  Y  cost  cost  this  I' 


101  S6.866.400.00  S75.600.00 

S398.160.00 

S367.500.00 

SI  80.350.00 

S20.826.000.00 

S12.801. 106.01 

S3.486.000.00 

S769.145.63 

102  SI 0.584.000.00  S180.000.00 

S6  36.000. 00 

S550.000.00 

S266.500.00 

S28.600.000.00 

55,154,178.54 

S3, 921, 500.00 

SI, 029, 303.44 

103  S8.122.800.00  S70.800.00 

S507.120.00 

S484.000.00 

S235.500.00 

S26.072.000.00 

SI  5,235,972.67 

SI  4.365.500.00 

S2.505.049.63 

d 

[page:  H  1  <  1 1  T  >  1  h  1  jJ 

_ 1 

±r 

Ready 

Figure  76.  “Viewing  the  new  report”  Window 
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APPENDIX  I:  PROTOTYPE  OF  ANALYSIS  FORMS 


Figure  77.  “Compare  two  units”  Form 


Figure  78.  “Compare  two  units  by  jobs”  Form 
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Figure  79.  “Compare  two  units  by  vehicles”  Fonn 


Figure  80.  “Compare  two  units  by  weapons”  Form 


Enter  Parameter  Value 


X] 


To  uniquely  identify  the  Unit  Type  you  wish  to  search  by,  just  enter  the  first  three  characters  of  that  field: 


OK  |  Cancel 


Figure  8 1 .  “Querying  the  unit  type”  Window 


Figure  82.  “Querying  the  unit  size”  Window 
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y  Microsoft  Access 


.Jfljx] 

0  t?-  fi  Y.  zl  II  X  'to  ©  °  M  *  >  m  w  itt  m 


Figure  83.  “Compare  units  by  type  and  size”  Query 


Figure  84.  “Copying  any  unit  in  the  database  as  a  proposed  one”  Window 
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Figure  85.  “Viewing  and  apply  “What  if’  method  on  all  proposed  units”  Fonn 


|  H  Microsoft  Access 

^jnjxjl 

Exit  3  WindowHlde  3  WinowUnhide 

Type  a  question  for  help  » 

Optimization  models 


S— 

nr 

n 

‘infantry  Batta  on  1 

Armor  Battallon.xls 

Return  to  Analysis 


Figure  86.  “Optimization  models”  Switchboard 
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APPENDIX  J:  BRIEF  USERS’  MANUAL 


1.  PURPOSE 

This  DSS  helps  the  users  (mainly  the  force  structure  planners)  to  establish  the  cost 
of  creating  and  maintaining  an  operational  military  unit,  which  in  turn  will  aid  the 
decision-makers  or  planners  in  tracking  and  monitoring  the  manpower  and  staffing 
requirements,  operational  support  requirements  and  the  proposal  or  approval  of  a  cost- 
effective  organization.  The  DSS  tool  can  also  be  used  to  perform  additional  functions 
such  as  monitoring  and  highlighting  job  vacancies  and  manpower  shortfalls  or  surpluses 
in  an  organization,  as  well  as  comparing  the  costs  of  maintaining  two  or  more  units  in  an 
organization. 

2.  GETTING  STARTED 

The  database  program  is  stored  in  a  filename,  entitled  “BDFDSS”.  Install  the 
program  by  copying  the  file  into  your  computer.  Before  you  are  allowed  to  access  or  use 
the  database  program,  you  must  be  an  authorized  user.  You  will  need  an  authorized  user 
id  and  password  to  access  the  program.  Please  see  your  department  system  administrator 
and  request  a  user  id  and  password  if  you  do  not  have  one  and  you  are  an  authorized  user. 
Once  you  enter  the  program  with  the  authorized  user  id  and  password,  a  menu 
switchboard  will  appear  and  you  will  be  ready  to  use  the  database  program. 


3.  USING  THE  SWITCHBOARD 

The  switchboard  shows  a  list  of  menus  on  which  you  can  find  the  options  to 
perform  the  necessary  tasks  as  defined.  There  are  four  main  menus,  comprising  Forms, 
Queries,  Reports,  and  Analysis.  Just  click  on  the  icon  to  access  the  submenu  functions 
you  need.  The  icon,  “Return  to  Main  menu”,  appears  in  all  submenus  and  allows  the 
users  to  return  to  the  main  menu  at  any  time  during  the  program  execution.  Figure  87 
shows  the  main  menu  switchboard  of  the  BDF  DS  tool. 
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Q  Microsoft  Access 


JSjxJ 

Exit  2  WindowHide  2  WmowUnhide  ^BTypea  question  for  help 


Figure  87.  Main  Menu  Switchboard 


4.  USING  FORMS 

The  forms  are  intended  to  allow  the  authorized  user  and  system  administrator  to 
ADD  new  and  MODIFY  existing  data  in  the  database.  Figure  88  depicts  the  “Forms” 
switchboard.  In  the  ADD  function,  you  can  choose  to  insert  new  types  of  unit,  weapons, 
jobs  or  vehicles.  You  can  also  choose  to  insert  a  particular  job  or  weapon  or  vehicle  into  a 
unit.  But  for  the  latter,  you  must  first  create  the  new  job,  weapon  or  vehicle  in  the 
database  before  you  can  insert  the  new  job  or  weapon  or  vehicle  into  a  unit. 
Additionally,  the  ADD  forms  are  supported  with  tool  bar  icons  (located  at  the  upper  part 
of  the  window)  for  record  editing,  navigation,  and  sorting  purposes. 

In  the  MODIFY  function,  you  can  choose  to  update  or  delete  existing  data  records 
or  fields  of  each  data  type.  Similarly,  MODIFY  forms  are  supported  with  tool  bar  icons 
that  have  two  extra  functions,  namely,  record  filtration  and  record  representation  via 
charts  or  pivot  tables.  All  ADD  forms  are  created  using  the  data  entry  form  format.  The 
lists  of  data  which  can  be  added  and  modified  are  given  as  follows: 

•  Unit 

•  Job 

•  Rank  with  Salary  Info. 
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•  Vehicle 

•  Weapon 

•  Jobs  to  a  Unit 

•  Vehicles  to  a  Unit 

•  Weapons  to  a  Unit 


H  Microsoft  Access 


Exit  2  WindowHide  2  WinowUnhide  Type  a  question  for  help 


Figure  88.  Forms  Switchboard 


5.  USING  QUERIES 

From  time  to  time,  users  may  want  to  query  the  data  to  answer  questions  or 
identity  problems  or  particular  situations.  Two  main  classes  of  queries  were  thus  created 
in  this  design.  The  users  can  choose  to  make  either  single  queries  or  multiple  queries  as 
shown  in  Figure  89. 
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Figure  89.  Queries  Switchboard 


a.  Single  Queries 

These  are  mainly  standard  queries,  which  are  created  to  provide  responsive  data 
to  the  users  and  to  facilitate  the  users’  query  requirements.  In  a  single  query,  the  query  is 
directed  only  at  a  single  table.  For  example,  the  users  can  query  the  list  of  units  or  the  list 
of  jobs  or  the  list  of  weapons,  etc  in  the  database.  Queries  may  be  directed  at  the 
following: 

•  Units 

•  Jobs 

•  Salaries 

•  Vehicles 

•  Weapons 

•  Manpower 

•  Vehicles  in  Units 

•  Weapons  in  Units 
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b.  Multiple  Queries 

For  these  queries,  users  are  allowed  to  direct  queries  at  two  or  more  tables.  For 
example,  the  users  can  make  use  of  multiple  queries  to  compare  the  operating  costs  of 
establishing  two  units  in  terms  of  manpower,  weapons,  and  vehicles.  The  lists  of  such 
queries  are  given  as  follows: 

•  Unit  manpower 

•  Unit  vehicles 

•  Unit  weapons 

•  Job  in  units 

•  Vehicle  in  units 

•  Weapon  in  units 

c.  Additional  feature 

Moreover,  the  users  are  also  allowed  to  conduct  further  searches  on  their  own  if 
the  standard  queries  above  do  not  meet  their  requirements.  In  other  words,  the  users  can 
create  their  own  query  based  on  all  available  tables  and  previously  created  queries  in  the 
database.  The  steps  for  executing  this  function  are  documented  in  the  Query  main  menu 
form  via  the  “Create  my  query”  and  “View  my  query(s)”  command  buttons. 


6.  USING  REPORTS 

A  report  is  a  fonnatted  display  of  database  data.  There  are  in  total  6  types  of 
reports  that  are  currently  included  in  this  database  system  as  shown  in  Figure  90  below. 
However,  it  is  possible  for  the  users  to  define  many  different  types  of  reports  based  on  the 
tables  and  queries  in  the  database.  Users  can  create  and  view  such  reports  by  following 
steps  similar  to  those  described  in  the  query  section  above.  For  the  given  reports,  the 
users  will  need  to  select  the  data  type  to  display.  For  example,  when  comparing  the 
manpower  between  two  units,  the  users  will  need  to  insert  the  unit  id  to  compare  the  data. 
The  different  types  of  reports  are  as  follows: 

•  List  of  jobs  in  Unit 

•  List  of  vehicles  in  Unit 

•  List  of  weapons  in  Unit 

•  Make  manpower  comparison  between  2  units 

•  Make  vehicles  comparison  between  2  units 

•  Make  weapons  comparison  between  2  units 
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Figure  90.  Reports  Switchboard 


7.  USING  ANALYSIS 

The  force  structure  planners  will  spend  most  of  their  time  using  the  functions  in 
the  Analysis  menu  shown  in  Figure  91  below.  Initially,  the  users  can  utilize  the  different 
types  of  comparisons  available  in  this  menu  to  see  the  units’  differences.  Secondly,  users 
can  simulate  any  unit  structure  in  the  database  by  copying  it  to  a  different  unit  id.  The 
copied  unit  structure  can  then  be  manipulated  and  analyzed  to  generate  other  scenarios 
needed  for  the  study.  Thirdly,  the  users  can  utilize  the  human  resource  optimization 
models  linked  to  the  program  to  support  their  assumptions  and  solutions  when  proposing 
a  unit  structure.  Also,  users  can  view  the  proposed  unit  structures  and  apply  the  “what  if’ 
technique  to  the  units’  resources  and  match  them  with  the  best  solutions  found  in  the 
optimization  models.  Finally,  the  users  can  see  the  unit  statistics  based  on  either  the 
number  of  jobs  that  refer  to  the  unit  budget  cost  or  the  number  of  occupied  jobs  that  refer 
to  the  unit  actual  cost. 
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Figure  91.  Analysis  Switchboard 


8.  SECURITY 

There  are  two  main  classes  of  users;  namely  the  force  structure  planners  and  the 
system  administrators.  The  main  responsibility  of  the  system  administrator  is  to  protect 
the  data  created  in  the  database  and  ensure  that  only  authorized  users  are  allowed  to 
access  and  use  the  data.  The  system  administrator  accomplishes  the  control  through  the 
granting  of  the  appropriate  access  rights  to  the  users.  All  authorized  users  will  be  given  a 
user’s  ID  and  a  password  in  order  to  access  the  database  system.  Additionally,  all 
developed  tables,  forms,  queries,  reports,  and  macros  are  protected  against  deletion  and 
alteration  by  regular  users. 
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